Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

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.


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.

Back to the top