Android Coding Style and Guidelines - GeeksforGeeks

25 Aug, 2021
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.
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:
Java
// This is Bad practiceclass myClass1{   int func2()  {    //...  }}  // This is good practiceclass 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:
Java
if (condition) {    body();}  // can be written as if(condition) body();  // But not likeif(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:
Java
// 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:
Java
@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.
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.
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,
Example: Declare iteration variable in for loop itself.
Java
int i = 0;  // bad practicefor(i= 0; i< 10; i++)     // Good practicefor(int i=0; i<10; i++){     // do your work}  // good practicefor(Iterator i = c.iterator(); i.hasNext()){    // do your work}
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 nam
ed 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. 
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”.
Picked
Android
Android
Writing code in comment?
Please use ide.geeksforgeeks.org,
generate link and share the link here.
Resource Raw Folder in Android Studio
Flutter - Custom Bottom Navigation Bar
How to Read Data from SQLite Database in Android?
Flexbox-Layout in Android
How to Post Data to API using Retrofit in Android?
Retrofit with Kotlin Coroutine in Android
Android Listview in Java with Example
Fragment Lifecycle in Android
How to Change the Background Color After Clicking the Button in Android?
How to Get Current Location in Android?