Skip to content

Coding style

Jump to bottom
Herman De Beukelaer edited this page Jun 3, 2016 · 6 revisions

This document describes the coding standards followed in the CoreHunter 3 project. Coding style is automatically verified with the Maven Checkstyle plugin during the verify phase. Any violations will fail the build. The checkstyle configuration file is contained in the CoreHunter build-tools module.

Source files

  1. Each top-level class, interface of enum resides in a source file of its own.
  2. The outer type name and file name should match. For example, a class Foo is required to be defined in a file Foo.java.

Imports

  1. Star imports are not allowed.
  2. Wrapping import statements is not allowed.

Packages

  1. Package names are all lowercase, with consecutive words simply concatenated together (no underscores). Digits are not allowed before the first dot nor immediately after a dot. Regex: ^[a-z]+(\.[a-z][a-z0-9]*)*$.
  2. Wrapping package statements is not allowed.

General formatting

  1. Tab characters are not allowed. Four spaces are used for indentation.
  2. Comments are indented at the same level as the surrounding code.
  3. The maximum line length is 120 characters, except for package or import statements and lines containing an URL. Wrapping package or import statements is not allowed.
  4. Whitespace around the Generic tokens (angle brackets) < and > should correspond to the typical convention. For more details, see http://checkstyle.sourceforge.net/config_whitespace.html#GenericWhitespace.
  5. Multiple statements per line are not allowed.
  6. Long-valued integer literals use an uppercase L suffix, never lowercase (to avoid confusion with the digit 1).
  7. Empty line separators are required after header, package, all import declarations, fields, constructors, methods, nested classes, static initializers and instance initializers. Static imports should be separated from other imports.
  8. When a line is broken at a dot, the break comes before the dot.
  9. When a line is broken at a comma, the break comes after the comma.
  10. When a line is broken at an operator, the break comes before the symbol.
  11. All names of classes, variables, methods, etc. consist of letters and digits only and are formatted in camel case, except for constants (see below). The abbreviation IT is allowed in the name of integration test classes. Also API is allowed.
  12. The names of classes, interfaces, enums and annotations start with an upper case letter.
  13. The names of non-static fields, static non-final fields, method and catch parameters, local variables and methods start with a lower case letter.
  14. The names of constants (static final fields) match the pattern ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$. This means that the names must contain only upper case letters and digits. Words are separated with underscores and the name is required to start with a letter. Multiple consecutive underscores are not allowed.
  15. For the name of type variables used in generic classes, interfaces and methods, there are two allowed styles:
  16. A single capital letter, optionally followed by a single number (e.g. E, T, T2).
  17. A name that complies with the rules for classes (see above) followed by a capital letter T or the word Type.
  18. Overload methods are grouped together.
  19. For a method definition, constructor definition, method call or constructor invocation, the left parenthesis is required to come immediately after the identifier, i.e. on the same line and without whitespace after the identifier.

Blocks

  1. Braces are compulsory, also in case of single-line blocks.
  2. The opening brace is on the end of the line. Only for enums this rule can be broken.
  3. The closing brace is preceded with a line break. However, an empty block or block-like construct may be closed immediately after it is opened ({}), unless it is part of a multi-block statement (one that directly contains multiple blocks: if/else-if/else or try/catch/finally). A line break is added after the closing brace if that brace terminates a statement or the body of a method, constructor or named class. For example, there is no line break after the brace if it is followed by else or a comma.
  4. A switch block always includes a default case, even if it contains no code.

Arrays

  1. The square brackets form a part of the type, not the variable: e.g. String[] args, not String args[].

Finalizers

  1. It is not allowed to define finalize() methods in a class.

Comments

  1. Empty if, else, try, catch, finally and switch blocks should contain a comment.
  2. A fall-through in a switch statement should be commented.

Javadoc

  1. The following at-clauses appear in this order if present: @param, @return, @throws, @deprecated.
  2. An at-clause is always followed by a description.
  3. When line-wrapping the description of an at-clause, an indentation of at least four spaces is used.

Clone this wiki locally