3.4Inline comments

Non-trivial code should be obligatory documented. It relates to: algorithms (for example, fast Fourier transform), not documented features usage, some non-trivial optimizations, etc.

It may be convenient to place specific comments indicating that some source code is not finalized yet and still require further changes or improvements. In the same time, intermediate source code versions may be released prior to such “finalization”. In that case, the following way should be used to declare intention of applying some modifications to that part of source code in the future:

// TODO: <Details of planned modification/improvement>

This comment should be placed either just before target source code part or at the end of the first line of target source code part.

Example:

// TODO: Use caching mechanism here.

Service service = getService();

4.Code formatting

4.1Indentation, spaces and braces

The following rules outline the formatting guidelines for indentation and braces:

• Indentation should be 4 space characters (tabs usage is prohibited).

• Open brace should reside on the same line as related construct.

• Case labels should use indentation.

• All flow control primitives (if, else, while, for, do, switch) shall be followed by braces, even if they have single operation.

• Methods, fields and nested types should be separated by single empty line. Related fields can be placed on the sequential lines however.

• When instruction spares several lines, second and subsequent ones should be indented with 4 space characters.

• If necessary, method logic can contain empty lines if it increases understandability (however, small methods strongly encouraged).

For example:

public class Point extends EventArgs {

private final double x;

private final double y;

public Point(double x, double y) {

this.x = x;

this.y = y;

}

public double getX() {

return x;

}

public double getY() {

return y;

}

public PointType getType() {

double radius = x * x + y * y;

if (Math.abs(radius – 1.0) < 0.000001) {

return PointType.PERIODIC;

}

if (radius < 1.0) {

return PointType.CONVERGING;

}

return PointType.DIVERGENT;

}

}

4.2Separation of operators and punctuators

Space character should be placed before and after the following operators and punctuators (if operator or punctuator is placed before line break, the space after it unnecessary):

+ - * / % & | ^ = < >

&& || << >> == != <= >= += -= *=

/= %= &= != ^= <<= >>=

Space before opening round bracket is optional.

Comma should be followed by space (but space is disallowed before comma).

Operators and punctuators can end line, but should not start line.

4.3Line length

It’s recommended not to create source code lines longer than 120 characters.

5.General style recommendations

5.1Anonymous methods

Use anonymous methods cautiously. Generally, apply the following rules:

• Use anonymous method if you need up to five code lines;

• Use anonymous method if you need capture one or two external variables.

6.References

The following materials are referenced within the document:

1. Java Code Conventions

7.Glossary

The glossary contains terms and abbreviations that you should be familiar with when reading the document:

Pascal Case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example:

BackColor, TransformationMatrix, DodgeTypeJawCrusher

Camel Case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. For example:

backColor, transformationMatrix, dodgeTypeJawCrusher

Uppercase

All letters in the identifier are capitalized. For example:

IO, UI

Uppercase with underscores

All letters in the identifier are capitalized and words are separated with underscores. For example:

MAX_VALUE, IDENTITY_TRANSFORM