Android id naming convention: lower case with underscore vs. camel case

I'm currently programming an application for the Android. Now what I found out is that you cannot place resource objects, say, an image in the drawable folder and name it like "myTestImage.jpg". This will give you a compiler error since camel case syntax is not allowed, so you'd have to rename it like "my_test_image.jpg".

But what about ids you define in the XML file. Say you have the following definition

<TextView android:id="@+id/myTextViewFirstname"
              android:layout_width="wrap_content"
              android:layout_height="wrap_content"
              android:text="Firstname" />

This is a valid definition, compiles and works just fine on my Android emulator although - as you see - I'm specifying the id in camel case syntax.

Now, the Android samples always use lower case and underscore. Is this just a naming convention to use lower case with underscore for the id's or may it cause problems on the real device?

Thx

The device will not complain if you use camel-case id names. For my first application I wrote all the ids in camel-case because I think it appears better in the Java code that way, and it works just fine.

I am slowly changing my mind on camel-case, though, because you end up with two different naming conventions - for example:

// This must be undescored due to naming constrictions
setContentView(R.layout.my_long_layout_name);

// Now this looks a little out of place
findViewById(R.id.myLongSpecificId);

I, too, wonder about the standards here. Google is inconsistent in their examples; sometimes they use all lowercase, sometimes they insert underscores, and sometimes they use camel-case.

If you take look at android.R.id.* fields, you will notice that all of them are in camel-case. So if the android ids are written in camel-case, I guess we have to follow this convention :)

i think it is good if we use the all small letters with underscores.

Just look at this(Adding to what Daniel had answered)

> // Camel Case TextView tvUserName = (TextView) findViewById(R.id.tvUserName);

	// Small Caps and Underscores
	TextView tvUserName = (TextView) findViewById(R.id.tv_user_name);

in my own experience I tend to get a little confused of the camel case convention in xml because when you link it to Java which also uses camel case(because it is the standard) it looks like a doppleganger.

If you look at some of Googles app samples such as:

https://github.com/google/iosched

They use underscores. So.... maybe that is how we should be doing it?

android:id="@+id/frag_account_button"
frag_account_button = ((ListView)view.findViewById(R.id.frag_account_button));

android:id="@+id/fragAccountButton"
fragAccountButton = ((ListView)view.findViewById(R.id.fragAccountButton));

First of all, there is no certain standard to define which one is more Proper but I have my own idea about that. My idea is reasonable to keeping XML id and java variable in the exact same name with the camel-case convention.

1. It is easy to reach the variable by searching for the project both XML and java side.

2. butterKnife library definition

   @BindView(R.id.infoTextView) TextViewFont infoTextView;

It is more proper to keep in this way.

I think if we use underscore convention for id in xml files and camel case convention for class fields then it will give better visibility to every developer to distinguish between xml ids and class fields.

xml file names (which is what is used in the drawable folder) must be all lower case separated by the underscore character _ since capitalized file names are not supported in xml.

If the Android's compiler is truly doing what you say restricting camel case (which seems rather odd) then you should stick to the established conventions.

Going against the grain will only cause unnecessary confusion. Keep things consistent in all places where possible.

If you see within Android Sample of ViewBinding layout files then you will find that ids of the views are with camel case.

So I guess it totally depends on the developer side what would be better for the team.