Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Trace Compass/Code Style
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.
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.
|ID is a word, Id is the psychological element
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.
|private int fCurrentCpu
|private final int fCpu
|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.