The rules below are not guidelines or recommendations, but strict rules. Contributions to Android generally will not be accepted if they do not adhere to these rules.
Not all existing code follows these rules, but all new code is expected to.
Java Language Rules
We follow standard Java coding conventions. We add a few rules:
- Exceptions: Never catch and ignore them without explanation.
- Exceptions: do not catch generic Exception, except in library code at the root of the stack.
- Finalizers: generally don't use them.
- Imports: Fully qualify imports
Java Library Rules
There are conventions for using Android's Java libraries and tools. In some cases, the convention has changed in important ways and older code might use a deprecated pattern or library. When working with such code, it's okay to continue the existing style (see Consistency). When creating new components never use deprecated libraries.
Java Style Rules
Programs are much easier to maintain when all files have a consistent style. We follow the standard Java coding style, as defined by Sun in their Code Conventions for the Java Programming Language, with a few exceptions and additions. This style guide is comprehensive and detailed and is in common usage in the Java community.
In addition, we enforce the following style rules:
- Comments/Javadoc: write it; use standard style
- Short methods: don't write giant methods
- Fields: should either be at the top of the file, or immediately before the methods that use them
- Local variables: limit the scope
- Imports: android; third party alphabetical; java(x)
- Indentation: 4 spaces, no tabs.
- Line length: 100 columns
- Field names: Non-public, non-static fields start with m.
- Braces: Opening braces don't go on their own line.
- Annotations: Use the standard annotations.
- Acronyms are words: Treat acronyms as words in names, yielding XmlHttpRequest, getUrl(), etc.
- TODO style: "TODO: write this description"
- Consistency: Look at what's around you!
- Logging: Be careful with logging. It's expensive.
Javatests Style Rules
- Naming test methods: testMethod_specificCase is ok
References
