Choose your code style
Add notes for:
- Qulice
- error_prone
- Qodana
Style is an often overlooked but very critical attribute of writing. The style of writing directly impacts the readability and understandability of the end product.
There are 2 main java code styles, and many variants.
Typically the discussion on style is 4-space or 2-space indentation (and
sometimes <TAB>):
An example of a variant style is Palantir based on Google code style.
It is up to you which one you should choose. But the style should be chosen and the style should be the same for everyone.
To maintain the same standard config/ide/eclipse-java-google-style.xml
or intellij-java-google-style.xml should be imported to your IDE.
Checkstyle should be configured based on the chosen standard.
With Java, one needs to rely on external tooling for linting. The most popular choice is:
For your editor, consider the sample
.editorconfig
file in this project.
It is respected by IntelliJ and many other code editors.
(The sample uses 80-character line limits as IBM and Hollerith punch cards
intended, and helpful for speed readers of code.
A point worthy of team discussion.)
The demonstration projects assume checkstyle configuration at
config/checkstyle/checkstyle.xml
This is the default location for Gradle, and configured for Maven in the
project.
The Checkstyle configuration used is stock
sun_checks.xml
(this is SUN default style for Java) with the addition of support for
@SuppressWarnings(checkstyle:...). Note that this format is overly
aggressive for Javadocs, and needs tweaking for most projects. See comments
in build.gradle about SUN vs Google styles for Java.
Spotless — For Gradle, use the
spotlessApply task to reformat; for Maven use the spotless:apply goal.
There is also support for sbt if you are working with a scala project.
In addition, Spotless has a configuration option called ratcheting. This allows you to be able to configure the plugin to only check or apply style formatting based on changes to files since a specified branch or commit (this can be both remote or local).
For instance if you configure this option with ratchetFrom 'origin/main'
then the plugin will look for any changes to files on commits ahead of origin/main.
This option could be very powerful for allowing you to incrementally apply
style changes to an existing codebase rather than affecting the entire codebase
in one commit. For more details, you can read here
for Gradle or here for Maven.
The tool behind the plugin supports many other languages, however if you use a build tool other than Gradle, Maven, or SBT you will have to write your own custom builder plugin.
- CleanThat is built into the Spotless plugin.
- Rewrite — General framework. for transforming source code with many extensions and plugins for different languages and frameworks. For Gradle, see Rewrite for Gradle with a focus on SUN style guides for Java; for Maven, see Rewrite for Maven with a focus on SUN style guides for Java
See the code repo for working examples.
This work is dedicated/deeded to the public following laws in jurisdictions
for such purpose.
The principal authors are: