Android Coding Style and Guidelines

While you writing code, there are some rules you need to follow to keep code easy to read and clean. If you are not new to coding, you probably already know about coding standards. Coding standards vary from person to person and can be different for different projects. Before starting adding or updating code in someone else's project or open source project, you should first look around to identify the coding style they've used and try to follow the same. Here are some commonly accepted coding standards for android which will help you to write clean code.

Standard Coding Style to Follow

1. Indent your code Properly with tabs or 4 white spaces.

2. Put braces on the same line as the code before them, not on their own line.

Example:

// This is Bad practice
class myClass1
{ 
  int func2()
  {
    //...
  }
}

// This is good practice
class MyClass {
    int func() {
        if(){
            //...
        }else{
            //...
        }
    }
}

3. If the condition and the body fit on one line, you may put it all on one line.

Example:

if (condition) {
    body();
}

// can be written as 
if(condition) body();

// But not like
if(condition)
    body(); // Bad Practice

4. Use TODO comments for code that is temporary, a short-term solution, or good enough but not perfect. These comments should include the string “TODO” in all caps, followed by a colon.

Example:

// TODO: Use boolean Flag instead of int constant.

5. Switch case should always have a “default” statement to catch unexpected values.

6. Use standard predefined annotations in code wherever needed.

Example:

@Deprecated 
// used to mark component which no longer should be used.

@Override 
// used to tell that declared method overrides method in superclass.

@Nullable
// tells that parameter, return value of method or field can be null.

@NonNull
// tells that parameter, return value of method or field can not be null.

Handling Exceptions

• You should never leave your catch block empty, even if you are too sure that exception will never occur.
• Try to catch exceptions separately, do not catch generic exceptions.
  • Try to use different “try” blocks for statements that can cause different exceptions. Ex.- separate parsing statements from Input statements into separate “try” blocks.
• If you are confident about ignoring exceptions, then you should put an appropriate comment explaining why exceptions can be ignored,

Loops

Example: Declare iteration variable in for loop itself.

int i = 0;

// bad practice
for(i= 0; i< 10; i++) 
  
// Good practice
for(int i=0; i<10; i++){ 
    // do your work
}

// good practice
for(Iterator i = c.iterator(); i.hasNext()){
    // do your work
}

Standard Naming Rules to Follow

Naming conventions in coding:

• Non-static, Non-public (i.e., private, default, and protected) field names should start with m, Ex.- int mVar.
• Static field names should start with s, Ex.- private static int sVar.
• Public fields should start with a lower case letter, Ex.- public int var.
• Public static final fields or constants should be in all caps with underscores, Ex.- public static final int MY_CONSTANT = 42.
• Class or interface name should always start with a capital letter and the first letter of the changing word should be also in capital Ex.- MyClass, MyInterface,  MyCustomViewClass
• The class should have comments at the top which clearly state the purpose of the class creation. Same for functions.
• The function name should always start with a small letter, and the first letter of the changing word should be capitalized. Ex.- public int registeNewUser(), 

Naming conventions in XML:

• Layout files should match the name of the Android components that they are intended. Ex.- layout file for LoginActivity.class should be named as activity_login.xml.
• When we are creating a layout that is going to be inflated by an Adapter, i.e., to populate a ListView or RecyclerView. In this case, the name of the layout should start with “item_”, Ex.- item_contact_card.xml.
• Layout resource id should use the naming convention where possible: <layout name>_<object type>_<object name>, Ex.- profile_imageview_avatar.
• When defining string in strings.xml, name of string should follow this syntax:  <purpose>_<where>, Ex.- <string name="hint_login_id">Enter your login ID</string>.
• Drawable files should be named as <prefix>_<description>, prefixes used for icons, buttons, and action Bar are ic_, btn_, ab_ respectively. Ex.- btn_sign_up.xml, dialog_warning.xml, menu_primary.xml. 

Handling Resources 

All resources that are being used in the project should be defined in the "res" folder of the application in the following format:

• If you need to use string values in the application, then it should be defined in “res/values/string.xml”.
• If you need to use color in the application, then it should be defined in “res/values/colors.xml”.
• If you need to use static arrays in the application, then it should be defined in “res/values/arrays.xml”.
• If you need to use static dimensions in the application, then they should be defined in “res/values/dimens.xml”.
• If you need to use specific or custom styles for components used in the application, it should be defined in “res/values/styles.xml”.