To maintain a level of quality in the codebase, the project maintains a set of coding and testing guidelines.
Indentation and spaces
- Four spaces, not tabs, are used for indentation.
- Trailing whitespaces should be removed in both code and comments.
There should be a space between keywords (
catch, etc.), parenthesis, and braces:
There should be a space before the curly braces in method definitions. Arguments are not padded (neither in definition nor invocation):
The project uses Checkstyle to enforce some of the formatting mentioned above. Violations will stop the build until fixed.
Javadocs are used to document the codebase itself. Interfaces are heavily documented with Javadocs so that implementing methods (annotated with
@Override) inherit the commenting.
At the time of this writing, various formats are used within the code.
Interfaces and classes
Interfaces should always be given first pick of clear names that convey their purpose. For example, if there is an interface representing a network device, and a class implementing it, the interface should be given the name
Device, and the class, something indicating that it implements the
Wherever possible, references should be made to the interface, and not the implementing class. This includes method parameters.
- Nested classes.
A class that implements functions specific to a particular class (e.g. its event handlers or services that it exports) should be implemented as an inner private class within the class. Such classes have names beginning with
- Data types.
Wherever possible, use a rich data type over a primitive (e.g.
long). This reduces ambiguity.
The codebase uses SLF4J for logging. Do NOT use
The logger should be private final, and associated with the particular class: