Skip to content

Code style conventions

Jump to bottom
Abhilash G edited this page Dec 5, 2018 · 1 revision

1. Imports

Auto ordering of imports should be applied. This function is available in Android Studio.

2. Package naming

General rule: com.companyname.projectname.directory.subdirectory. In case of complex project names, there can be two cases of package naming, for example:

  • com.example.mypackage.*
  • com.example.my_package.*

It is however preferable to use the variant without the underscore. It is shorter and simplier.

3. File naming

3.1 Class naming

Class names should always be written in UpperCamelCase. For classes that extend an Android component, the name of the class should end with the name of the component; for example: ExampleActivity, ExampleFragment, ExampleService, ExampleDialog.

3.2 Naming Resources files

Layout files should match the name of the Android components that they are intended for but moving the top level component name to the beginning. For example, if we are creating a layout for the SignInActivity, the name of the layout file should be activity_sign_in.xml.

4. Code guidelines

4.1 Use of access-modifiers

Always use access-modifiers (private, protected, public) wherever possible. Use protected for variables defined in a parent class and reuse them in all child classes. Use private for variables needed only in current class.

4.2 Field definition and naming

Fields should be defined at the top of the file and they should follow the naming rules listed below.

  • Private, non-static field names start with m.
  • Private, static field names start with s.
  • Other fields start with a lower case letter.
  • Static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.

Example:

public class ExampleClass {
     public static final int INT_CONSTANT = 30;
     public static final String STRING_CONSTANT = “STRING_CONSTANT”;
     public int exampleFields;
     private static SingletonClass sSingleton;
     int mPackagePrivate;
     private int mPrivateField;
     protected int mProtectedField;
}

4.3 Class member ordering

There is no correct solution for this but using a logical and consistent order will improve code readability. It is recommendable to use the following order:

  • Constants
  • Fields
  • Constructors
  • Override methods and callbacks (public or private)
  • Public methods
  • Private methods
  • Inner classes or interfaces

4.4 Methods naming

Please use meaningful method names that succinctly describes the purpose of the method, thereby making your code self-explanatory which further reduces the need for additional comments. Compose method names using mixed case letters, which begin with a lowercase letter followed by an uppercase letter for each subsequent word.

Begin method names with a strong action verb (for example, deposit). If the verb is not descriptive enough by itself, include a noun (for example, addInterest). Add adjectives if necessary to clarify the noun (for example, convertDollarsToEuro).

Use the prefixes get and set for getter and setter methods. Getter methods merely return the value of a instance variable; setter methods change the value of a instance variable. For example, use the method names getBalance and setBalance to access or change the instance variable balance.

If the method returns a boolean value, use is or has as the prefix for the method name. For example, use isOverdrawn or hasCreditLeft for methods that return true or false values. Avoid the use of the word not in the boolean method name, use the ! operator instead.

For example, use !isOverdrawn instead of isNotOverdrawn.

4.5 Parameter ordering in methods

When programming for Android, it is quite common to define methods that take a Context. If you are writing a method like this, then the Context must be the first parameter. For callback interfaces the opposite is true, they should always be the last parameter.

Examples:

// Context always go first
public User loadUser(Context context, int userId);
// Callbacks always go last
public void loadUserAsync(Context context, int userId, UserCallback callback);

4.6 Line-wrapping strategies

There isn't an exact formula that explains how to line-wrap and quite often different solutions are valid. However, there are a few rules that can be applied to common cases.

Method chain case

When multiple methods are chained in the same line - for example when using Builders - every call to a method should go in its own line, breaking the line before the .

Bad code:

Picasso.with(context).load("image").into(imageView);

Good code:

Picasso.with(context)
        .load("image")
        .into(imageView);

Long parameters case

When a method has many parameters or its parameters are very long we should break the line after every comma , Bad code:

loadPicture(context,”image”,mImageCompanyPicture, clickListener, "Picture title");

Good code:

loadPicture(context,
        "image",
        mImageCompanyPicture,
        clickListener,
        "Picture title");

4.7 Constants

Many elements of the Android SDK such as SharedPreferences, Bundle or Intent use a key-value pair approach so it's very likely that even for a small app you may end up writing a lot of String constants.

When using one of these components, you must define the keys as a static final fields and they should be prefixed as shown below.

SharedPreferences - PREF_
Bundle - BUNDLE_
Fragment Arguments - ARG_
Intent Extra - EXTRA_
Intent Action - ACTION_

Note that the arguments of a Fragment - Fragment.getArguments() - are also a Bundle. However, because this is a common use of Bundles, we define a different prefix for them.

Example:

// Note the value of the field is the same as the name to avoid duplication issues
static final String PREF_EMAIL = "PREF_EMAIL";
static final String BUNDLE_AGE = "BUNDLE_AGE";
static final String ARG_USER_ID = "ARG_USER_ID";
// Intent-related items use full package name as value
static final String EXTRA_NAME = "com.example.project.Const.EXTRA_NAME";
static final String ACTION_OPEN = "com.example.project.Const.ACTION_OPEN";

5. Resources naming

5.1 Naming of resource IDs

IDs should always be prefixed with the name of the element in lowercase underscore. For example:

TextView - tv_
ImageView - iv_
Button - btn_
Menu - menu_

5.2 Strings

String names start with a prefix that identifiers the section they belong to. For example registration_email_hint or registration_name_hint. If a string doesn't belong to any section then you should follow the rules below:

error_ - An error message
msg_ - A regular information message
title_ - A title, i.e. a dialog title
action_ - An action such as "Save" or "Create"
Clone this wiki locally