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-co

Answer 1

The newest Android Eclipse plugins create some of the files you mention automatically when you create a new project. From that, the naming is something like that:

layout/activity_main.xml
menu/activity_main.xml
...

I followed this scheme with e.g.

layout/fragment_a.xml
layout/fragment_b.xml
...

So it's something like with package names, from general to detailed. It also allows for neat sorting.

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

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 4

I don't think there is a convention for this yet . each company has its own rules and I don't think anyone cares much about it here.

For me , I prefer putting the name to be bound to the context . for example , if there is an activity called "MainActivity" , its layout name would be "main_activity.xml" , and for each resource associated with this activity , I add a prefix "main_activity" so that I know that it uses it . same goes for the ids used for this activity .

The reason I use those naming is that it's easier to find them, delete if needed , and you won't get them replaced with others if you use android libraries since the names are quite unique.

I also try as much as possible to give meaningful names , so you will usually not see "listView" or "imageView2" as ids , but something like "contactsListView" and "contactImageView" . the same name (or similar) would also match the variables inside the java code, in order to make it easier to find.

So , in short, my tips are:

• try to avoid numbers inside the names . they usually don't mean much , and show that you've only used drag&drop for the UI designer .

• for demos, POCs and for questions here , don't worry yourself about naming .

• try to add a prefix to all of the names of the resources (including ids) to show which context they belong to , and to achieve uniqueness.

• give meaningful names wherever possible .

Answer 5

As to naming conventions and/or best practices, I often follow this md file of ribot/android-guidelines repository in github that has project and coding guidelines enlisted in it.

Answer 6

Every body uses his own, The main goal is to avoid mistakes and misinterpretation, specially when others read your code. Though syntax highlighting, and auto code inspection in modern IDE's makes it pretty point less.

But these naming conventions also make it very convenient when code completion is turned on. For example just type m and auto complete will show you a list of class fields.

But many times you have to work with other's code, which doesn't use such convention. such protected variables and overridden method parameters just add to the confusion.

Few examples:

• Prefix class variables with m , and make static finals variables all caps, with _ separating words. Don't prefix any thing to lower scope variables.

• Name layout after the UI parent, for example act_main.xml , frg_detail.xml , itm__act_main__list1.xml ; for an activity MainActivity, a fragment DetailFragment, item layout for a ListView in MainActivity with id list1, respectively.

• Name element Id's in xml layouts like: lsv__act_main__list1 for a ListView and btn__act_main__submit for a `Button element. This makes them much easier to find with auto complete.