Trace Compass/Code Style

Note: The contents of this page is obsolete and is migrated to Trace Compass Wiki.

---

The project's coding style is defined in Eclipse project settings, which are committed in the tree, so simply hitting Ctrl+Shift+F in Eclipse should auto-format the current file.

The project follows the standard Oracle code convention found here

Basically, 4 spaces for indentation, no tabs.

Code	Compliance
\s\s\s\scode	good
\tcode	bad
\t\s\t\scode	bad

No trailing spaces, this can be easily seen in the gerrit code reviews.

Always use brackets and they should start on the same line. See 1TBS (One true brace style)

We've turned off the auto-wrapping and unwrapping of lines, because it was doing more harm than good. Please wrap lines to reasonable lengths (100-120 is a good soft limit). Do NOT wrap after '.' (method invocations), it makes the code less readable. After '(' or ',' is usually good.

Acronyms in names should be avoided when possible. When they are industry standard, they are to be used though. They should be in ALL CAPS if they are under 3 letters long, if they are 3 letters or more, only capitalize the first letter. A rule of thumb is, if you invented the acronym it should not be in the code.

Examples

Code	Compliance	correct alternative
getCPU	bad	getCpu
getElem	bad	getElement
getID	good	ID is a word, Id is the psychological element
getSIPIE	bad	getStreamInputPacketIndexEntry

Fields should start with an f then use CamelCase. It is recommended to use @Nullable and @NonNull annotations when possible and to make everything immutable (final) when it makes sense. If there are many immutable objects, it is a good idea to add Current to the mutable fields.

Name	Type	Mutable?	Declaration
cpu	int	yes	private int fCurrentCpu
cpu	int	no	private final int fCpu
found	boolean	yes	private boolean fFound (fCurrentFound makes no sense!)

Adding the f in front of the field avoids the difficulty of naming parameters, as there is less ambiguity and no need to explicitly call the this pointer.

Attempt to make methods under 50 lines long, This allows them to fit more easily into a monitor, but also helps keeping code simpler. Also avoid having more than 4 scopes depth in a method. Overly complex methods are harder to validate and more prone to being buggy.

Finally remember that we are human and can be spoken to. If you have a better idea, don't hesitate to discuss it with us.