Style Guide

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).

Other

This style guide is adapted from the Signal App Android Style Guidelines. For any style questions not addressed here please refer to Google's ASOP Java Style Guide and Kotlin Style Guide, and prioritize consistency with the existing codebase.