Android naming convention

Question

I am looking for a thorough Android naming convention suggestion. I found a little bit here:

http://source.android.com/source/code-style.html#follow-field-naming-conventions

which says:

• 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.

Yet I am looking for something much more extensive covering all aspects of Android:

• how to name layouts and views within,
• how to name menus
• how to name styles
• how to name database tables (singular, plural) and fields within
• etc

If there is some generally accepted suggestion I would just love to follow that. All SDKs seem to go their own way so I am particular interested in the Android way to do it.

Answer 1

ribot's Android Guidelines are a good example of standard naming conventions:

Naming convention for XML files:

activity_<ACTIVITY NAME>.xml - for all activities
dialog_<DIALOG NAME>.xml - for all custom dialogs
row_<LIST_NAME>.xml - for custom row for listview
fragment_<FRAGMENT_NAME>.xml - for all fragments

Naming convention for component/widget in xml files:

All components for X activity must start with the activity name all component should have prefix or short name like btn for Button For example,name for login activity component should be like following.

activity_login_btn_login
activity_login_et_username
activity_login_et_password

Short name of major components:

Button - btn
EditText - et
TextView - tv
ProgressBar - pb
Checkbox - chk
RadioButton - rb
ToggleButton - tb
Spinner - spn
Menu - mnu
ListView - lv
GalleryView - gv
LinearLayout -ll
RelativeLayout - rl

Answer 2

This is an excellent collection of best practices to start with: https://github.com/futurice/android-best-practices

Here's what I use. I'll also copy from that link.

Object naming

• Don't use the m or s prefix as per Google guidelines. I've stopped for years and I find it easier without them. The IDE will tell you when you're using something private or static; it seems like an obsolete convention.
• CONSTANTS start with caps
• Acronyms should only capitalize the first letter. For example, functionUrl and unitId. Not unitID.
• Prefix with the type of object. For example a TextView which contains a name would be tvName. An EditView with a password would be etPass.
• If it's something usually used only once in an activity (e.g. ListView), don't be afraid to just call it lv.
• If it's not an object type just name it by it's function. For example, if it's a string that holds the ID, name it as id, not stringId. The IDE will tell you when it's a string or a float or a long.
• Keep it legible. Use something like Pass instead of Password.
• Within the XML, name should be underscore with no capitals, e.g. tv_name and et_pass
• Put the android:id as the first attribute in the XML.

File naming

• Prefix layouts with the type it is. E.g. fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.
• For the classes, categorize them into folders, but use suffixes. For example, /activities/MainActivity.java or /fragments/DeleteDialog.java. My folders are activities, fragments, adapters, models, and utils.
• Adapters should say how and when they are used. So a ListView adapter for ChatActivity might be called ChatListAdapter.

colors.xml and dimens.xml as a pallete

• For color, use names like gray_light, not button_foreground.

• For dimens, use names like spacing_large, not button_upper_padding.

• If you want to set something specific for your button color or padding, use a style file.

strings.xml

• Name your strings with keys that resemble namespaces, and don't be afraid of repeating a value for two or more keys.

• Use error.message.network, not network_error.

Reasoning

The purpose of naming conventions is not to make everything neat and consistent. It's there to flag possible mistakes and improve workflow. Most of these are designed to be convenient for keyboard shortcuts. Try to focus around minimizing bugs and improving workflow rather than looking nice.

Prefixes are great for those, "What's the name of that TextView?" moments.

Suffixes are there for the things which you don't access so often in that manner, but can be confusing. For example, I may not be sure whether I put my code in the Activity, Fragment, or Adapter of that page. They can be dropped if you like.

XML ids are often in lowercase and uses underscores just because everyone seems to do it this way.

Answer 3

CONSISTENCY
Everyone (unless working in teams) will have their own convention and which one you choose does not matter. Making sure it is consistent throughout the whole application does matter.


STRUCTURE
Personally, I use a naming convention like this as it runs from the class name down to component and is consistent throughout the xml:

• CLASS: <ClassName>
• ACTIVITY: <ClassName>**Activity**
• LAYOUT: classname_activity
• COMPONENT IDS: classname_activity_component_name

An example of this would be OrderActivity.class, order_activity.xml, order_activity_bn_cancel. Notice all the XML is in lowercase.

ABBREVIATING LAYOUTS
If you would like to use shorter names to keep the code tidier; then another method can be to abbreviate ALL the names in XML aswell as the layouts.

An example of this would be OrderActivity.class: ord_act.xml, ord_act_bt_can, ord_act_ti_nam, ord_act_tv_nam. I break down the names into three but this depends how many similar names you have

ABBREVIATING COMPONENT TYPES
When abbreviating component types try to keep these consistent too. I normally use two letters for the component type and three letters for the name. However sometimes the name will not be necessary if that is the only element of that type in the layout. The principle of the ID is to be unique

• COMPONENT IDS: nam_act_component_nam

COMPONENT TYPE ABBREVIATIONS (This list shows two letters which is plenty)
Frame Layout: fl
Linear Layout: ll
Table Layout: tl
Table Row: tr
Grid Layout: gl
Relative Layout: rl

Text View: tv
Button: bt
Check Box: cb
Switch: sw
Toggle Button: tb
Image Button: ib
Image View: iv
Progress Bar: pb
Seek Bar: sb
Rating Bar: rb
Spinner: sp
WebView: wv
Edit Text: et

Radio Group: rg
List View: lv
Grid View: gv
Expandable List View: el
Scroll View: sv
Horizontal Scroll View: hs
Search View:* se
Tab Host: th
Video View: vv
Dialer Filter: df

Include: ic
Fragment: fr
Custom View (other): cv