• Nomenclature
  • Packages
  • Classes & Interfaces
  • Methods
  • Fields
  • Variables & Parameters
  • Misc
• Declarations
  • Access Level Modifiers
  • Fields & Variables
  • Classes
  • Enum Classes
• Spacing
  • Indentation
  • Line Length
  • Vertical Spacing
• Getters & Setters
• Brace Style
• Switch Statements
• Annotations
• XML Guidance
  • XML File Names
  • Indentation
  • Use Context-Specific XML Files
  • XML Attribute Ordering
• Language
• Copyright Statement
• Smiley Face
• Credit

On the whole, naming should follow Java standards.

Package names are all lower-case, multiple words concatenated together, without hypens or underscores:

BAD:

com.RayWenderlich.funky_widget

GOOD:

com.raywenderlich.funkywidget

Written in UpperCamelCase. For example RadialSlider.

Written in lowerCamelCase. For example setValue.

Written in lowerCamelCase.

Static fields should be written in uppercase, with an underscore separating words:

public static final int THE_ANSWER = 42;

Fields naming example:

public class MyClass {
  public static final int SOME_CONSTANT = 42;
  public int publicField;
  private static MyClass singleton;
  int packagePrivate;
  private int private;
  protected int protected;
}

Written in lowerCamelCase.

Single character values to be avoided except for temporary looping variables.

In code, acronyms should be treated as words. For example:

BAD:

XMLHTTPRequest
String URL
findPostByID

GOOD:

XmlHttpRequest
String url
findPostById

Access level modifiers should be explicitly defined for classes, methods and member variables.

Prefer single declaration per line.

BAD:

String username, twitterHandle;

GOOD:

String username;
String twitterHandle;

Exactly one class per source file, although inner classes are encouraged where scoping appropriate.

Enum classes should be avoided where possible, due to a large memory overhead. Static constants are preferred. See http://developer.android.com/training/articles/memory.html#Overhead for further details.

Enum classes without methods may be formatted without line-breaks, as follows:

private enum CompassDirection { EAST, NORTH, WEST, SOUTH }

Indentation is using spaces - never tabs.

Indentation for blocks uses 4 spaces:

BAD:

for (int i = 0; i < 10; i++) {
  Log.i(TAG, "index=" + i);
}

GOOD:

for (int i = 0; i < 10; i++) {
    Log.i(TAG, "index=" + i);
}

Indentation for line wraps should use 4 spaces (not the default 8):

BAD:

CoolUiWidget widget =
        someIncrediblyLongExpression(that, reallyWouldNotFit, on, aSingle, line);

GOOD:

CoolUiWidget widget =
    someIncrediblyLongExpression(that, reallyWouldNotFit, on, aSingle, line);

Lines should be no longer than 120 characters long.

There should be exactly one blank line between methods to aid in visual clarity and organization. Whitespace within methods should separate functionality, but having too many sections in a method often means you should refactor into several methods.

For external access to fields in classes, getters and setters are preferred to direct access of the fields. Fields should rarely be public.

However, it is encouraged to use the field directly when accessing internally (i.e. from inside the class). This is a performance optimization recommended by Google: http://developer.android.com/training/articles/perf-tips.html#GettersSetters

Only trailing closing-braces are awarded their own line. All others appear the same line as preceding code:

BAD:

class MyClass
{
  void doSomething()
  {
    if (someTest)
    {
      // ...
    }
    else
    {
      // ...
    }
  }
}

GOOD:

class MyClass {
  void doSomething() {
    if (someTest) {
      // ...
    } else {
      // ...
    }
  }
}

Conditional statements are always required to be enclosed with braces, irrespective of the number of lines required.

BAD:

if (someTest)
  doSomething();
if (someTest) doSomethingElse();

GOOD:

if (someTest) {
  doSomething();
}
if (someTest) { doSomethingElse(); }

Switch statements fall-through by default, but this can be unintuitive. If you require this behavior, comment it.

Alway include the default case.

BAD:

switch (anInput) {
  case 1:
    doSomethingForCaseOne();
  case 2:
    doSomethingForCaseOneOrTwo();
    break;
  case 3:
    doSomethingForCaseOneOrThree();
    break;
}

GOOD:

switch (anInput) {
  case 1:
    doSomethingForCaseOne();
    // fall through
  case 2:
    doSomethingForCaseOneOrTwo();
    break;
  case 3:
    doSomethingForCaseOneOrThree();
    break;
  default:
    break;
}

Standard annotations should be used - in particular @Override. This should appear the line before the function declaration.

BAD:

protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
}

GOOD:

@Override
protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
}

Since Android uses XML extensively in addition to Java, we have some rules specific to XML.

View-based XML files should be prefixed with the type of view that they represent.

BAD:

• login.xml
• main_screen.xml
• rounded_edges_button.xml

GOOD:

• activity_login.xml
• fragment_main_screen.xml
• button_rounded_edges.xml

Similarly to Java, indentation should be four characters.

Wherever possible XML resource files should be used:

• Strings => res/values/strings.xml
• Styles => res/values/styles.xml
• Colors => res/color/colors.xml
• Animations => res/anim/
• Drawable => res/drawable

Where appropriate, XML attributes should appear in the following order:

• id attribute
• layout_* attributes
• style attributes such as gravity or textColor
• value attributes such as text or src

Within each of these groups, the attributes should be ordered alphabetically.

Use US English spelling.

BAD:

String colour = "red";

GOOD:

String color = "red";