Coding Style Java

Intro:

• These are the coding style guidelines that should be used for writing Java code
• Rules must always be followed
• Best practives should be followed, but exceptions can be madedocument out of this

Rules:

• Indentation is two spaces
• In our main code base (i.e. no tests), modifier private is not allowed for fields and methods; protected should be used instead; this allows our users to work around problems or extend the engine easier
• Lines of code must not exceed 100 characters
• If method signatures exceed 100 characters, each parameter must be on a new line
• Always use @Override when you override or implement a method
• Do not use @author tags; Do not remove existing tags
• Do not use star imports
• All unused imports must be removed
• Use Diamond Operator (List<String> list = new ArrayList<>();), try-with-resources, underscores in numeric literals when it improves readability
• Avoid redundant interface modifiers: public (methods / fields), static (fields) & final (fields)
• Bracket placement: Kernighan and Ritchie style ("Egyptian brackets") for nonempty blocks and block-like constructs; plus: opening brackets of classes and methods go on the same line as the declaration

return new MyClass() {
  @Override 
  public void method() {
    if (condition()) {
      try {
        something();
      } catch (ProblemException e) {
        recover();
      }
    } else if (otherCondition()) {
      somethingElse();
    } else {
      lastThing();
    }
  }
};

• Annotations placement:

  • Methods, fields and classes: Above the declaration, one annotation per line
  • Method parameters and local variables: On the same line

• Always use a default branch in switch-case statements, may be omitted for switch statements on enums if all values are used

• Files must be encoded in UTF-8

• Imports: (Tobias)

  • static imports in a single block
  • non-static imports in a single block, divided from static imports by a blank line
  • Import order consistent for all IDEs

• Local variables must be declared close to their fist usage, not at the beginning of the block

• Use the recommended order of modifiers: public protected private abstract default static final transient volatile synchronized native strictfp

• No trailing whitespace; no whitespace on empty lines

• Indentation for chaining method calls on new lines is four spaces

• Names of static final member variables (class fields) are uppercase with words separated by underscores ("_"); All other variable names are camel case

• TODO: Everyone should commit the same line endings

• TODO: Consistent placement of new lines of a source file (Nikola) => exact proposal to be made

Best Practices:

• Within the same source file, the ordering of annotations should be consistent

• TODO: No IDE warnings should be committed

  • Eclipse/IntelliJ settings that produce the same amount of warnings should be used