Code Style Guidelines

Indentation

1. Use spaces instead of tabs.
2. Blocks are 2 spaces.

Field Naming Conventions

1. Please do not use "Hungarian" notation (instance variable names preceded by an 'm', static variable names preceded by an 's' and so on).
2. Start variable names with a lowercase letter, and use camelCase rather than under_scores.
3. Constants (public/private static final) are ALL_CAPS_WITH_UNDERSCORES.

Line Length

To the greatest extent possible, please wrap lines at 100 characters.

Write Short Methods

When possible, keep methods as small and focused as possible. The public methods of a class should read like a book, and essentially just aggregate the actions of private methods within that class. The private methods of a class should, as much as possible, be written in "functional style" -- meaning that their actions are confined to their local scope and their return value without having any other side effects on instance variables of the class.

Comments

Each class should include a class-level Javadoc comment above the class declaration, describing what the overall purpose of the class is. This should be the only comment included in the code. If you find yourself writing a method, and are tempted to include comments on what parts of a method are doing, such as:

public void process() {
  // Do the first thing
  int something;
  something = 0;

  // Do the second thing
  int somethingElse;
  somethingElse = something + 1;

  // Do the third thing
  int somethingElseAgain;
  somethingElseAgain = somethingElse + 2;
}

...treat this as a sign that your method is not correctly factored. Break each comment block up into its own method, and name each method exactly what you would have written as a comment:

public void process() {
  int result = doTheFirstThing();
  result     = doTheSecondThing(result);
  result     = doTheThirdThing(result);
}

public int doTheFirstThing() {
  return 0;
}

public int doTheSecondThing(int result) {
  return result + 1;
}

public int doTheThirdThing(int result) {
  return result + 2;
}

The only exceptions for comments of smaller granularity than class-level should be cases where you are doing something exceptionally "clever," such as using a double-dispatch pattern and need to warn the casual reviewer not to factor out callbacks into a base class.

Fully Qualify Imports

When you want to use class Bar from package foo, there are two possible ways to import it:

import foo.*;
import foo.Bar;

Please use the latter.

Import Order

The ordering of import statements is:

1. Android imports
2. Imports from third parties (com, junit, net, org)
3. java and javax

Within each grouping, the imports should be sorted alphabetically, with capital letters before lower case letters (e.g. Z before a). There should be a blank line between each major grouping.

Use Annotations

Specifically, use @Override whenever possible, for clarity.

Treat Acronyms As Words

In variable names and class definitions, try to treat acronyms as words (XmlHttpRequest instead of XMLHTTPRequest, for instance).

Be careful what you log!

Whenever you insert a log statement, please think carefully about whether it could ever possibly leak sensitive information.

Copyright Statement

Every file should have a copyright statement at the top. The package statement and import statements should follow, each block separated by a blank line.

Don't use finalizers

There are no guarantees as to when a finalizer will be called, or if it will be called at all.