Style Guide

Formatting

• In general, we try to utilize the default Android Studio style for code formatting. To automatically format your code in the current source code window, use Cmd+Option+L (on Mac) or Ctrl+Alt+L (on Windows and Linux).
• Use tabs instead of spaces.

Naming Conventions

• Start variable names with a lowercase letter, and use camelCase rather than under_scores.
• Constants (public/private static final) are ALL_CAPS_WITH_UNDERSCORES.

Short Methods

When possible, keep methods small and focused. 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" with 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.

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.