Formatting and layout contribute significantly to the readability and maintainability of the codebase. These guidelines should be adhered to consistently throughout the project.
Indentation
Indentations should be made with 4 spaces. This applies to classes, methods, and blocks of code enclosed in braces {}. Avoid using tabs.
public class Sample {
public void method() {
// 4 space indentation
}
}
Whitespace
Braces
“K & R style” braces should be used. Opening braces don’t go on their own line and they do go on the same line as the code before them.
class ExampleClass {
void exampleMethod() {
if ( condition ) {
// statements
} else {
// statements
}
}
}
Blocks
An if, if-else, while, do-while, for statement should always brace its body. Exception: If the entire body of the if, if-else, while, do-while, for statement fits on one line, it may optionally be left un-braced.
if ( condition ) {
return;
}
// Or optionally:
if ( condition ) return;
Vertical whitespace
Two lines of vertical whitespace should surround:
- Method definitions:
public Constructor() { this( 0 ); } public Constructor( final int foo ) { } private void foo() { } private void bar() { }
One line of vertical whitespace should surround:
- Initializers:
private static final int INT; static { INT = 2; } public final String var; - Class definitions:
public class Mess { public static class Foo { } protected class Bar { } }
Horizontal whitespace
Add a single space within:
- Array initializer braces:
int[] X = new int[] { 1, 3, 5, 6, 7, 87, 1213, 2 }; - Parentheses in method declarations and calls:
public void foo( int x, int y ) { foo( 5, i ); - Parentheses in control structures:
if ( 0 < x && x < 10 ) { for ( int i = 0; i < x; i++ ) { while ( x != y ) { switch ( e.getCode() ) { try ( MyResource r1 = getResource() ) { } catch ( MyException e ) { synchronized ( this ) {
Deviations from these guidelines
While these style conventions are intended as guidelines rather than strict rules, adhering to them is crucial for maintaining a consistent, understandable, and easily navigable codebase. Deviations from these guidelines should be rare and well-justified.
The fundamental objective of these guidelines is to enhance the clarity and maintainability of our code. Therefore, if strict adherence to these guidelines compromises these objectives, and deviation provides a clear benefit, it is acceptable to diverge. In such cases, the justification should be evident in the clarity and comprehensibility of the code itself.
