ustwo™ Android Coding Standards

Table of contents

• Code
  • Style
  • Indentation
  • Line length
  • Whitespace
  • Imports
• XML
  • Indentation
  • Structure
  • Id names
  • Example
• Documentation
  • Javadoc
  • Comments
• Version control

Code

Style

Follow the official Android code style guidelines: http://source.android.com/source/code-style.html

Indentation

Use 4 spaces per indentation level and no tabs.

Line Length

Stick within the 120 char line limit. Use line breaks to split up code according to the style guidelines.

Whitespace

Code should not have any trailing whitespace to avoid creating unnecessary diff issues. Please setup your IDE to remove these as a save action.

Imports

Please setup your IDE to remove all unused imports as a save action.

XML

Indentation

Use 4 spaces per indentation level and no tabs. Each attribute should appear on its own line.

Structure

XML tags should be ordered as follows: 'xmlns' first, then id, then layout_width and layout_height then alphabetically.

Add a space between the closing slash and the final attribute. E.g. android:textSize="10dp" />

IDE Auto format

Automatic formatting rules for our coding standards are stored in an Android Studio file inside the root of this repository. Please use File > Import Settings and select "android_studio_settings.jar" to ensure you get the same rules.

Id names

Layout resource ids should use the following naming convention where possible:
<layout name>_<object type>_<object name>
E.g.

home_listview_hotels
hotel_item_imageview_star_rating

Example

Given a layout called profile.xml:

<?xml  version="1.0"  encoding="utf-8"?> 
<LinearLayout 
    xmlns:android="http://schemas.android.com/apk/res/android" 
    android:layout_width="match_parent" 
    android:layout_height="match_parent"
    android:orientation="vertical" > 

    <!-- Avatar icon -->
    <ImageView
        android:id="@+id/profile_imageview_avatar" 
        android:layout_width="wrap_content" 
        android:layout_height="wrap_content" />
</LinearLayout> 

Documentation

Javadoc

Any new classes that are committed must include a class descriptor Javadoc along with: @author [email protected] Javadoc any public methods, variables and constants. Javadoc private methods where beneficial.

Comments

Use in-line commenting to help the next developer who might be editing your code, even if it seems obvious now. Inline comments should appear on the line above the code your are commenting. Comment XML View elements using <!-- Comment -->.

Version control

No commented out code must be committed unless you have a very good reason that is clearly described in a comment by the code you are ommitting.

For further details on branching strategies used at ustwo please see: http://ustwo.com/blog/branching-strategies-with-git/