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
Switches checkstyle functionality to spotless. Sets ratchetFrom to
origin/main. This will mean it will only fail on files recently changed.
Pull formatting from OpenSearch.
Signed-off-by: John Mazanec <[email protected]>
Copy file name to clipboardexpand all lines: DEVELOPER_GUIDE.md
+27
Original file line number
Diff line number
Diff line change
@@ -74,6 +74,33 @@ You can import the OpenSearch project into IntelliJ IDEA as follows.
74
74
2. In the subsequent dialog navigate to the root `build.gradle` file
75
75
3. In the subsequent dialog select **Open as Project**
76
76
77
+
## Java Language Formatting Guidelines
78
+
79
+
Taken from [OpenSearch's guidelines](https://github.com/opensearch-project/OpenSearch/blob/main/DEVELOPER_GUIDE.md):
80
+
81
+
Java files in the OpenSearch codebase are formatted with the Eclipse JDT formatter, using the [Spotless Gradle](https://github.com/diffplug/spotless/tree/master/plugin-gradle) plugin. The formatting check can be run explicitly with:
82
+
83
+
./gradlew spotlessJavaCheck
84
+
85
+
The code can be formatted with:
86
+
87
+
./gradlew spotlessApply
88
+
89
+
Please follow these formatting guidelines:
90
+
91
+
* Java indent is 4 spaces
92
+
* Line width is 140 characters
93
+
* Lines of code surrounded by `// tag::NAME` and `// end::NAME` comments are included in the documentation and should only be 76 characters wide not counting leading indentation. Such regions of code are not formatted automatically as it is not possible to change the line length rule of the formatter for part of a file. Please format such sections sympathetically with the rest of the code, while keeping lines to maximum length of 76 characters.
94
+
* Wildcard imports (`import foo.bar.baz.*`) are forbidden and will cause the build to fail.
95
+
* If *absolutely* necessary, you can disable formatting for regions of code with the `// tag::NAME` and `// end::NAME` directives, but note that these are intended for use in documentation, so please make it clear what you have done, and only do this where the benefit clearly outweighs the decrease in consistency.
96
+
* Note that JavaDoc and block comments i.e. `/* ... */` are not formatted, but line comments i.e `// ...` are.
97
+
* There is an implicit rule that negative boolean expressions should use the form `foo == false` instead of `!foo` for better readability of the code. While this isn't strictly enforced, if might get called out in PR reviews as something to change.
98
+
99
+
In order to gradually introduce the spotless formatting, we use the
100
+
[ratchetFrom](https://github.com/diffplug/spotless/tree/main/plugin-gradle#ratchet) spotless functionality. This makes
101
+
it so only files that are changed compared to the origin branch are inspected. Because of this, ensure that your
102
+
origin branch is up to date with the plugins upstream when testing locally.
103
+
77
104
## Build
78
105
79
106
OpenSearch k-NN uses a [Gradle](https://docs.gradle.org/6.6.1/userguide/userguide.html) wrapper for its build.
0 commit comments