These are our basic style rules for new Java code in LanguageTool. For IntelliJ IDEA, you might want to use these inspection settings.
- Indent by 2 spaces.
- Use curly braces even if there's only one statement in the
if
block. - Do not use
final
for parameters or local variables, but write your code as if there was afinal
, i.e. do not re-assign local variables. Configure your IDE to help you with that.- For IntelliJ IDEA, the warnings (called "inspections") to activate are "Reuse of local variable" and "Assignment to method parameter".
- Use
final
for member variables if possible. - Try to make classes immutable. That means that an object, once created, cannot be changed anymore. This helps making code more robust. Obviously, not everything in a complex object-oriented software can be immutable.
- Do not remove public methods, but mark them deprecated and keep them
working. Use the
@deprecated
javadoc tag to document the method/class to be used instead. - Add a
@since x.y
javadoc annotation to all new non-private methods, withx.y
being the version number of the next release. - Add
@Nullable
to methods that might returnnull
, no matter if these methods are public or not. - Do not share same package path among submodules/subprojects,
ex. between
language-en
andlanguage-core
. It is known assplit package
problem that prevent a migration for Java Platform Module System (JPMS) introduced in Java 9. Each individual language module should have its own and unique package path which will end with a language code, ex.org.languagetool.language.en
andorg.languagetool.language.rules.en
for English language project.
Examples for proper use of whitespace:
if (var == 2) {
statements;
}
if (var != 3) {
statements;
} else {
statements;
}
if (var == 1 && foo == 5) {
statements;
} else if (condition) {
statements;
} else if (condition) {
statements;
}
try {
statement;
} catch (Exception e) {
statement;
} finally {
statement;
}