This style guide is different from other you may see, because the focus is centered on readability for print and the web. We created this style guide to keep the code in our tutorials consistent.

Our overarching goals are conciseness, readability and simplicity.

Thia is inspired by Raywenderlich

This style-guide is somewhat of a mash-up between the existing Java language style guides, and a tutorial-readability focused Swift style-guide. The language guidance is drawn from the Android contributors style guide and the Google Java Style Guide. Alterations to support additional readability in tutorials were inspired by the raywenderlich.com Swift style guide.

It is possible to get Android Studio to adhere to these style guidelines, via a rather complex sequence of menus. To make it easier, we've provided a coding style that can be imported into Android Studio.

First, clone this repository and run install.sh.

Then, open Android Studio. To set this codestyle as the default, select File > Other Settings > Default Settings...:

In Editor > Code Style, choose the Scheme to be raywenderlich.com:

From now on, projects you create should follow the correct style guidelines.

• 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

On the whole, naming should follow Java standards.

Package names are all lowercase, with consecutive words simply concatenated together (no underscores, no hyphens).

BAD:

com.example.deepSpace
com.example.deep_space

GOOD:

com.example.deepspace

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;

As distasteful as it is, field naming should follow the Android source code naming conventions:

• Non-public, non-static field names start with an m.
• Static field names start with an s.

For example:

public class MyClass {
  public static final int SOME_CONSTANT = 42;
  public int mPublicField;
  private static MyClass sSingleton;
  int mPackagePrivate;
  private int mPrivate;
  protected int mProtected;
}

Note: You can set Android Studio to follow this convention. See this SO link for details http://stackoverflow.com/questions/22732722/intellij-android-studio-member-variable-prefix

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 }

Spacing is especially important in MoldedBits code, as code needs to be easily readable as part of the tutorial. Java does not lend itself well to this.

Indentation is using spaces - never tabs.

Each time a new block or block-like construct is opened, the indent increases by two spaces. When the block ends, the indent returns to the previous indent level. The indent level applies to both code and comments throughout the block.

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);
}

Terminology Note: When code that might otherwise legally occupy a single line is divided into multiple lines, typically to avoid overflowing the column limit, this activity is called line-wrapping.

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

The prime directive of line-wrapping is: prefer to break at a higher syntactic level. Also:

When a line is broken at a non-assignment operator the break comes before the symbol. This also applies to the following "operator-like" symbols: the dot separator (.), the ampersand in type bounds (<T extends Foo & Bar>), and the pipe in catch blocks (catch (FooException | BarException e)). When a line is broken at an assignment operator the break typically comes after the symbol, but either way is acceptable. This also applies to the "assignment-operator-like" colon in an enhanced for ("foreach") statement. A method or constructor name stays attached to the open parenthesis (() that follows it. A comma (,) stays attached to the token that precedes it.

BAD:

Counter.getInstance().
    getCount();
    
if (value != null && 
    value.equals(value2)

GOOD:

Counter.getInstance()
    .getCount();
    
if (value != null
    && value.equals(value2)

When there are multiple continuation lines, indentation may be varied beyond +4 as desired. In general, two continuation lines use the same indentation level if and only if they begin with syntactically parallel elements.

Lines should be no longer than 100 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

Prefer Lombok @Getter and @Setter annotations.

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 two 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";

The following copyright statement should be included at the top of every source file:

/*
 * Copyright (c) 2016 Razeware LLC
 * 
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 * 
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 * 
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 */