Android coding standard

Coding Standards
Design by - Rakesh Kumar Jha Email – rkjhaw@hotmail.com
Android Coding Standard
1. ANDROID RESOURCE NAMES
a. Dimension
i. For dimensions, use “dp” and for text size, use “sp”. Do not use “px”.
b. File Naming
i. Layout - file is included with activity file, use – “_activity.xml”
ii. View - file included with view, use “_view.xml”
iii. Activity – file included with _Activity.java
iv. Service – file include with _Service.java
c. string.xml
i. Messages - prefix name with “msg_”
ii. Labels - prefix name with “lbl_”
d. colors.xml
i. Color Name - prefix color names with “color_”
e. Font
i. create “fonts” folder and place the “.ttf” file inside
f. Widget
i. EditText - prefix the name with edtitext_
ii. Button – prefix the name with btn_
iii. ImageView – prefix the name with imageview_
iv. TextView – prefix the name with textview_
v. RadioButton – prefix the name with radiobutton_
g. raw - raw folder for static XML, json files or media file
h. Prefix icon name with “ic_” and background image with “bg_”

Coding Standards
i. Images of different dimensions should be used for ldpi, mdpi, hdpi and xhdpi
j. For all messages and labels, store the data in string.xml
k. style.xml – All widget properties should defined here
l. package – grouped all relevant module code into single package
2. CODE STYLE GUIDELINES FOR CONTRIBUTORS
2.1 Java standard
2.1.1 Throw the exception up to the caller of your method
2.1.2. Throw a new exception that's appropriate to your level of abstraction
2.1.3. Handle the error gracefully and substitute an appropriate value in the catch {} block
2.1.4. Don't Use Finalizers
Pros: can be handy for doing cleanup, particularly of external resources.
Cons: there are no guarantees as to when a finalizer will be called, or even that it will be called at all.
Decision: we don't use finalizers.
2.1.5. Fully Qualify Imports
When you want to use class Bar from package foo, there are two possible ways to import it:
1. import foo.*;
Pros: Potentially reduces the number of import statements.
1. import foo.Bar;
Pros: Makes it obvious what classes are actually used. Makes code more readable for maintainers.
Decision: Use the latter for importing all Android code. An explicit exception is made for java standard libraries (java.util.*, java.io.*, etc.) and unit test code (junit.framework.*)

Coding Standards
2.2. Use Javadoc Standard Comments
 Every file should have a copyright statement at the top
 Then a package statement and import statements should follow
 And then there is the class or interface declaration
/*
* Copyright (C) 2010 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*/
Multi line Comment for
/**
* Does X and Y and provides an abstraction for Z.
*/
2.2.1. Every class and nontrivial public method you write must contain a Javadoc comment with at least one sentence describing what the class or method does.
Examples:
/** Returns the correctly rounded positive square root of a double value. */
static double sqrt(double a) {
}
or
/**
* Constructs a new String by converting the specified array of
* bytes using the platform's default character encoding.
*/
public String(byte[] bytes) {
...
}

Coding Standards
2.3. Write Short Methods
 If a method exceeds 40 lines or so, think about whether it can be broken up without harming the structure of the program.
2.4. Define Fields in Standard Places
 Fields should be defined either at the top of the file, or immediately before the methods that use them
2.5 Limit Variable Scope
 The scope of local variables should be kept to a minimum
 Each variable should be declared in the innermost block that encloses all uses of the variable
 Local variables should be declared at the point they are first used.
Set s = null;
try {
s = (Set) cl.newInstance();
} catch(IllegalAccessException e) {
throw new IllegalArgumentException(cl + " not accessible");
} catch(InstantiationException e) {
throw new IllegalArgumentException(cl + " not instantiable");
}
 Loop variables should be declared in the for statement itself unless there is a compelling reason to do otherwise:
for (int i = 0; i n; i++) {
doSomething(i);
}
2.6. Order Import Statements
The ordering of import statements is:
1. Android imports
2. Imports from third parties (com, junit, net, org)
3. java and javax
To exactly match the IDE settings, the imports should be:

Coding Standards
 Alphabetical within each grouping, with capital letters before lower case letters (e.g. Z before a).
 There should be a blank line between each major grouping (android, com, junit, net, org, java, javax).
This style was chosen such that:
 The imports people want to look at first tend to be at the top (android)
 The imports people want to look at least tend to be at the bottom (java)
 Humans can easily follow the style
 IDEs can follow the style
2.7. Use Spaces for Indentation
 We use 4 space indents for blocks.
 We never use tabs.
 We use 8 space indents for line wraps, including function calls and assignments
 Yes
String s =
somethingVeryLong(…);
 No
String s =
somethingVeryLong(…);
2.8. Follow Field Naming Conventions
 Non-public, non-static field names start with m.
 Static field names start with s.
 Other fields start with a lower case letter.
 Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.
public class MyClass {
public static final int SOME_CONSTANT = 42;
public int publicField;
private static MyClass sSingleton;
int mPackagePrivate;
private int mPrivate;

Coding Standards
protected int mProtected;
}
2.9. Use Standard Brace Style
 Braces do not go on their own line; they go on the same line as the code before them
class MyClass {
int func() {
if (something) {
// ...
} else if (somethingElse) {
// ...
} else {
// ...
}
}
}
 We require braces around the statements for a conditional.
 Except, if the entire conditional (the condition and the body) fit on one line, you may (but are not obligated to) put it all on one line.
if (condition) {
body();
}
And this is legal:
if (condition) body();
But this is still illegal:
if (condition)
body(); // bad!
2.10. Limit Line Length
 Each line of text in your code should be at most 100 characters long.

Coding Standards
 Exception: if a comment line contains an example command or a literal URL longer than 100 characters, that line may be longer than 100 characters for ease of cut and paste.
 Exception: import lines can go over the limit because humans rarely see them. This also simplifies tool writing.
2.11. Use Standard Java Annotations
 Annotations (e.g. @Override) can be listed on the same line with the language element.
 If there are multiple annotations, or parameterized annotations, they should each be listed one-per-line in alphabetical order.
2.12. Android standard practices for the predefined annotations in Java are:
 @Deprecated:
 The @Deprecated annotation must be used whenever the use of the annotated element is discouraged.
 If you use the @Deprecated annotation, you must also have a @deprecated Javadoc tag and it should name an alternate implementation.
 In addition, remember that a @Deprecated method is still supposed to work.
Note - If you see old code that has a @deprecated Javadoc tag, please add the @Deprecated annotation.
 @Override:
 The @Override annotation must be used whenever a method overrides the declaration or implementation from a super-class.
Note - if you use the @inheritdocs Javadoc tag, and derive from a class (not an interface), you must also annotate that the method @Overrides the parent class's method.
 @SuppressWarnings:
 The @SuppressWarnings annotation should only be used under circumstances where it is impossible to eliminate a warning.
 If a warning passes this "impossible to eliminate" test, the @SuppressWarnings annotation must be used, so as to ensure that all warnings reflect actual problems in the code.
 When a @SuppressWarnings annotation is necessary, it must be prefixed with a TODO comment that explains the "impossible to eliminate" condition.
 This will normally identify an offending class that has an awkward interface. For example:

Coding Standards
// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
@SuppressWarnings("generic-cast")
List<String> blix = Utility.rotate(blax);
2.13. Treat Acronyms as Words
 Treat acronyms and abbreviations as words in naming variables, methods, and classes.
 The names are much more readable:
Good
Bad
XmlHttpRequest
XMLHTTPRequest
getCustomerId
getCustomerID
class Html
class HTML
String url
String URL
long id
long ID
2.14. Use TODO Comments
 Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.
 TODOs should include the string TODO in all caps, followed by a colon:
// TODO: Remove this code after the UrlTable2 has been checked in.
And
// TODO: Change this to use a flag instead of a constant.
2.15. Log Sparingly
 The logging facilities provides five different levels of logging.
 Error
 Warning
 Informative
 Debug

Coding Standards
 Verbose
 ERROR:
 This level of logging should be used when something fatal has happened
 This level is always logged.
 WARNING:
 This level of logging should use when something serious and unexpected happened,
 INFORMATIVE:
 This level of logging should use be to note that something interesting to most people happened.
 DEBUG:
 This level of logging should be used to further note what is happening on the device that could be relevant to investigate and debug unexpected behaviors.
 VERBOSE:
 This level of logging should be used for everything else.
 Any string building will be stripped out of release builds and needs to appear inside the if (LOCAL_LOGV) block.
2.16. Be Consistent
 Our practice – be consistent throughout the project
2.17. Break Things into Small Pieces
2.18. Follow Normal Capitalization Rules
 Classes start with uppercase letter
public class SomeClass { … }
 Constants use all caps
public static final double GOLDEN_RATIO = (1 + Math.sqrt(5.0))/2;
 Everything else starts with lowercase letter
 Instance variables, local variables, parameters to methods, package names

Coding Standards
Note - Android does not currently enforce a specific style for writing Javadoc comments, but you should follow the Sun Javadoc conventions

Android coding standard

More Related Content

Similar to Android coding standard (20)

More from Rakesh Jha (20)

Android coding standard