You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+33Lines changed: 33 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,6 +51,39 @@ Common pitfalls and fixes
51
51
Linting & style
52
52
- The root does not expose an obvious global formatting tool (no Spotless or root Checkstyle detected). Use the existing code style. Run `./gradlew check` to execute configured verification tasks.
53
53
54
+
Testing conventions
55
+
- Use AssertJ for assertions (import `org.assertj.core.api.Assertions`), not JUnit's `Assertions`.
56
+
- Test class naming: `<ClassName>Test.java` in the same package under `src/test/java`.
57
+
- Test class visibility: use package-private (no `public` modifier) for test classes.
58
+
- Test method naming: `should<ExpectedBehavior>` pattern (e.g., `shouldReturnEmptyArrayForNullInput`).
59
+
- Use given/when/then comments with trailing colons to structure test methods (e.g., `// given:`, `// when:`, `// then:`, `// when/then:`).
60
+
- For cleanup steps, use `// cleanup:` comment section at the end of the test method.
61
+
- Prefer project collections (e.g., `MutableArray`) over JDK collections (e.g., `ArrayList`) in tests when appropriate.
62
+
- Use proper imports instead of fully qualified class names in test code.
63
+
- When adding new public methods, ensure corresponding unit tests are added.
64
+
- Use JUnit's `@TempDir Path tempDir` parameter injection for tests that need temporary directories instead of manually creating temp directories with `Files.createTempDirectory()`.
65
+
- For resources created outside `@TempDir` (e.g., `Files.createTempFile()`), add explicit cleanup in the `// cleanup:` section.
66
+
- For `assertThat()` calls: break method chains onto new lines with indentation when the assertion has arguments or multiple chained methods (e.g., `assertThat(result)\n .isEqualTo("expected")`). Short simple assertions can stay on one line.
67
+
- For fluent builder/method chains: break onto new lines with indentation (e.g., `tempDir\n .resolve("level1")\n .resolve("level2")`).
68
+
69
+
Javadoc conventions
70
+
- All public classes, interfaces, and methods should have javadoc.
71
+
- Javadoc must include `@since` tag with version (e.g., `@since 10.0.0`).
72
+
- Use short, active-voice descriptions (e.g., "Returns an array" not "Return an array").
73
+
- Do not use trailing periods in `@param` and `@return` descriptions (e.g., `@param value the value` not `@param value the value.`).
74
+
- Include `@param` and `@return` tags for non-trivial methods.
75
+
- Omit javadoc for simple getters/setters (e.g., `getArch()`, `setArch(String)`); they are self-explanatory.
76
+
- Omit obvious field comments that just repeat the field name (e.g., `/** The name. */ private String name;`).
77
+
- Omit obvious constant comments (e.g., `/** The constant FOO. */ public static final String FOO = "foo";`).
78
+
- Type parameter descriptions should use consistent format: "the type of..." (e.g., `@param <T> the type of elements` not `@param <T> the element type`).
79
+
- Do not generate javadoc for implementation classes (only interfaces and public API classes).
80
+
- For `@see` tags, avoid duplicate references (e.g., use `@see Math#sin(double)` not `@see Math#sin(double) Math#sin(double)`).
81
+
- For functional interfaces:
82
+
- Consumer descriptions must include "and returns no result" (e.g., "Represents an operation that accepts an int and an object argument, and returns no result.").
83
+
- Use type-specific @param descriptions (e.g., "the int argument", "the object argument") instead of generic "the first argument".
84
+
- Function @return should use "the function result" for consistency.
85
+
- Predicate @return should use "true if the arguments match the predicate".
Copy file name to clipboardExpand all lines: .github/skills/generate-javadoc.md
+58-7Lines changed: 58 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,6 +8,8 @@ When the user asks to:
8
8
- Generate javadocs for a module
9
9
- Add documentation to public APIs
10
10
- Document interfaces/classes with `@since` tags
11
+
- Review and fix existing javadocs
12
+
- Clean up javadoc formatting
11
13
12
14
## Requirements
13
15
@@ -16,23 +18,42 @@ When the user asks to:
16
18
2.**Skip implementation classes** - files in `impl/` packages are NOT documented
17
19
3.**Skip test classes** - files in `src/test/` are NOT documented
18
20
21
+
### What to Omit
22
+
1.**Simple getters/setters** - methods like `getArch()`, `setArch(String)` are self-explanatory
23
+
2.**Obvious field comments** - avoid comments that just repeat the field name (e.g., `/** The name. */ private String name;`)
24
+
3.**Obvious constructor javadocs** - avoid comments like "Instantiates a new Foo"
25
+
4.**Obvious constant comments** - avoid comments like "The constant FOO" for `public static final String FOO`
26
+
27
+
### Formatting Rules
28
+
1.**Active voice** - use "Returns" not "Return", "Creates" not "Create"
29
+
2.**No trailing periods** - in `@param` and `@return` descriptions (e.g., `@param value the value` not `@param value the value.`)
30
+
3.**No duplicate @see references** - use `@see Math#sin(double)` not `@see Math#sin(double) Math#sin(double)`
31
+
4.**Lowercase @param/@return descriptions** - start with lowercase (e.g., `@param value the value` not `@param value The value`)
32
+
5.**Consistent type parameter format** - use "the type of..." pattern (e.g., `@param <T> the type of elements` not `@param <T> the element type`)
33
+
6.**Descriptive @param names** - for functional interfaces, use type-specific descriptions (e.g., "the int argument", "the object argument") instead of generic "the first argument"
34
+
35
+
### Functional Interface Conventions
36
+
1.**Consumer descriptions** - always include "and returns no result" (e.g., "Represents an operation that accepts an int and an object argument, and returns no result.")
37
+
2.**Function @return** - use "the function result" for consistency
38
+
3.**Predicate @return** - use "true if the arguments match the predicate" or "true if the arguments match the predicate, false otherwise"
39
+
4.**Supplier @return** - describe what is supplied (e.g., "the char value" not just "a result")
40
+
19
41
### Javadoc Standards
20
42
Each documented element must include:
21
43
22
44
1.**Class/Interface level:**
23
-
- Short description of purpose
24
-
-`@param` for type parameters (if generic)
25
-
-`@author JavaSaBr`
45
+
- Short description of purpose (active voice)
46
+
-`@param` for type parameters with meaningful descriptions (if generic)
26
47
-`@since 10.0.0`
27
48
28
49
2.**Method level:**
29
-
- Short description for ALL methods
50
+
- Short description for non-trivial methods
30
51
-`@param` and `@return` only for **non-trivial** methods
31
52
-`@since 10.0.0`
32
53
-`@throws` only when explicitly thrown
33
54
34
55
3.**Constants/Fields:**
35
-
- Short description
56
+
- Short description (only if not obvious from the name)
36
57
-`@since 10.0.0`
37
58
38
59
### Example Format
@@ -42,7 +63,6 @@ Each documented element must include:
42
63
* An immutable array interface that provides type-safe, indexed access to elements.
43
64
*
44
65
* @param <E> the type of elements in this array
45
-
* @author JavaSaBr
46
66
* @since 10.0.0
47
67
*/
48
68
publicinterfaceArray<E> extendsIterable<E> {
@@ -79,6 +99,37 @@ public interface Array<E> extends Iterable<E> {
79
99
}
80
100
```
81
101
102
+
### Functional Interface Example
103
+
104
+
```java
105
+
/**
106
+
* Represents an operation that accepts an int and an object argument, and returns no result.
107
+
*
108
+
* @param <B> the type of the object argument
109
+
* @since 10.0.0
110
+
*/
111
+
@FunctionalInterface
112
+
publicinterfaceIntObjConsumer<B> {
113
+
114
+
/**
115
+
* Performs this operation on the given arguments.
116
+
*
117
+
* @param arg1 the int argument
118
+
* @param arg2 the object argument
119
+
* @since 10.0.0
120
+
*/
121
+
voidaccept(intarg1, Barg2);
122
+
}
123
+
```
124
+
125
+
### Common Fixes When Reviewing Existing Javadocs
126
+
- Change "Return the" to "Returns the"
127
+
- Change "Compare the" to "Compares the"
128
+
- Remove trailing periods from `@param` and `@return` lines
0 commit comments