...
Our guidelines are based on the Java Code Conventions, although we do not follow it strictly, except for those white-space rules that jcheck enforeces. The Java Code Conventions were drawn up at the dawn of time and are in sore need of a revision! For example 80-character line lengths was probably good advice in 1996, but in 2013 we have w-i-d-e monitors and we also like descriptive method and variable names. This leads to long lines and horrible wrapping when limited to 80 characters!.
This document captures what rules we use. Any violations of these rules should be corrected either during a code review, or when discovered. By having a single consistent set of rules that we apply throughout the codebase, we make it easier to:
...
Not everybody will like all of the code style rules, but hopefully most people will like most of them. More important, by following these rules we will have a consistent codebase with all the aforementioned benefits. This is a "living document" and will be amended as we go along. When new issues arise, we will add them to this list.
Whitespace
As mentioned above, some of the white-space rules are enforced by jcheck. The rest are conventions to which we should all strive to adhere.
Enforced by jcheck
- No trailing whitespace. Most (all?) IDEs can be configured to automatically trim trailing whitespace
- Use Spaces not Tabs.TABs.
- Use Unix-style (LF) line endings. No DOS-style (CR-LF) line endings.
Encouraged by Convention
- Use 4 space indentation
- Keep the single empty Use a single new-line at the end of every file
- Insert a space blank line between the Copyright notice and the package statement
- Insert a space blank line between the package statement and any import statements
- There should be one space blank line between the last import statement and the class documentation...
Overview
Content Tools
ThemeBuilder