style_guide.md

This file is an addition to Google's Java Style Guide which you can view here. This is split up into two parts: points from which this style guide differs from Google's and additions to Google's style guide.

Additions

Variable declarations

Var usage: only when clear

Replacing the explicit type definition in a local variable declaration/initialisation may be replaced by the var word for type inference, only if it is clear from the initialisation what the actual type would be, even for someone who does not necessarily know the rest of the codebase. For example, this is a place where this is allowed:

var text = "Hi"; //allowed, it's clear from the right-hand side that this is a String

However, this is a place where local type inference is not allowed:

var data = getData(); //disallowed, it's unclear what type data would be

Usage of local type inference is always a may, never a must. When in doubt whether local variable type inference would be acceptable, don't use it and resort to the explicit type name.

Differences

2.3.1 (original):
Tab characters may be used for indentation.

3 (original):
This project uses MIT license, therefore no license or copyright information at the top.

3.3.1 (original):
Wildcard imports, static or otherwise, may be used.

3.3.3 (original):
The import statements do not have to be in ASCII sort order, but import statements starting with the same main package name should be grouped.

4.2 (original):
Indentation uses 4 spaces or one tab.

4.4 (original):
The column limit is 120 characters.

4.6.2 (original):
Point 8: Only the first one is correct, the second one isn't:

//correct
new int[] {5, 6}

//incorrect
new int[] { 5, 6 }

4.8.1 (original):
Constants should always be on separate lines and should never be like an array initializer.

4.8.2.1 (original):
Multiple variable declarations in one line are allowed.

4.8.3.1 (original):
An array initializer should never be in a matrix like grid. Either all one the same line, or all on separate ones.

4.8.4.2 (original):
Fall through does not necessarily have to be commented.

4.8.5 (original):
Annotations should always be above the member class/method/field and there should always be one per line.

5.2.4 (original):
Constants are either enum values or fields marked with static and final.

7.1.1 (original):
A Javadoc should never be on one line. You should always use the first example.