Google's Java Coding Standards
Google has recently released their complete definition of coding standards for Java source code. These are hard-and-fast rules that are clearly enforceable, and are followed universally within Google. It covers not only formatting, but other types of conventions and coding standards.
The document is broken up into 6 main sections: Source File Basics, Source File Structure, Formatting, Naming, Programming Practices, and Javadoc. Source File Basics talks about filenames, file encoding, whitespace characters, and special characters. Source File Structure talks about license information, package and import statements, and class member ordering. Formatting talks about braces, indents, line wrapping, whitespace, parentheses, enums, arrays, switch statements, annotations, comments, and modifiers. Naming talks about identifiers (package, class, method, constant, field, local variable, type variable) and defines CamelCase. Programming Practices talks about @Override, exceptions, static members and finalizers. Javadoc talks about how to format Javadoc and where it is required.
Here are a few items contained in the guide.
- No wildcard imports.
- Overloads appear sequentially.
- Braces are used even when the body is empty or contains a single statement.
- 2 spaces indentation.
- Column limit can be 80 or 100 characters.
- No C-style array declarations.
- The default statement in switch statements are required.
- Modifiers appear in the order recommended by the Java Language Specification.
- Constants use CONSTANT_CASE. Note that every constant is a static final field, but not all static final fields are constants.
2 Spaces? Rly?
Re: 2 Spaces? Rly?
Re: Style Validation
* Fix indentation
* Organize imports (to enforce the wild-carding rules).
* Add braces
You can then cover the rest of it using the built-in checkstyles plugins:
Or defining their own. Checkstyles has ANT / Maven tasks that can be run as part of a build. The eclipse plugin highlights issues as your code.
You would still run findbugs during a policing build to find bugs (obviously), but checkstyles is a good add for your java environment / build setup if you want to enforce a common setting of coding styles across a development team.
Do also look at the eclipse formatting rules as well as they can be implemented more quickly, while less easy to enforce in a build.
Just use tabs people and end this stupid argument. Spaces are for between words.
K&R braces considered harmful
There is one and only one true brace style:
bar(); // (should be indented 4 spaces, but the webform loses them)
Anything else is unreadable, incorrect, communist, and the mark of the beast.
Re: K&R braces considered harmful
K&R ("Egyptian") braces have been part of Sun/Oracle Java conventions since those conventions existed. Hence, the vast majority of Java projects use them. Let's all be friends anyway, OK? :)
I've been using Sun/Oracle Java conventions on all my projects with very minor tweaks, such as expanding line length limit to 120 characters and banning tabs.
Thinking of switching to Google Style though. 2 spaces for indents might make more sense after some getting used to.