by Colin Miller
Thousands of Android apps, including most of the ones I've commercially worked on, use an 'm' prefix in front of private member variables. A lot of people seem to view it as "The Android Way" and how you're supposed to name your variables in an Android app. When pressed as to why, one would be pointed to the Android Code Style for Contributors page for the Android Open Source Project. It's pretty clear that this is how you're supposed to label your variables, isn't it?
Not really. You see the rules is specific for the Android Open Source Project. It's for contributing to the Android Open Source project itself. So if you want to submit new APIs or libraries to the base of Android to be included in the next version of the Operating System, then your code must conform to those rules or it will not be accepted. But these rules are just for that single project; the one of the Android OS. Requiring it for your own work on an independent Android app really makes no sense. But why do people do it anyway?
Coding conventions aren't a new thing. Many projects have coding conventions to keep the code looking uniform. This is really helpful, especially in larger projects, to have designated ways to format your code and name your variables. It makes a code base look unified and understandable to people looking into the project. As you look over the code, you'll know that a variable declared in ALL_CAPS is a static constant where as something named with firstLetterLowerCamelCase that it's probably a method; and FirstLetterUpperCamelCase is a class. These things are useful for being able to glance at code and get contextual clues as to the purpose of the code without having to see all of the declarations.
Most of the code styles for Android actually already existed with Java Code Conventions document written in 1997. This gives naming conventions for classes, methods, and variables. While they're not required, following them gives Java programmers a basic understanding of code by the layout and structure of names. This is common among many languages, and a useful tool that should be used for people writing code in those languages. However, the conventions of the Android Open Source Project are not those of a language, or even a platform, just one of a specific project.
That project is the Android Open Source Project itself, and that is fine. Many projects have naming and code style requirements that extend or override that of the language. However, the AOSP rules are for that project alone, not all Android projects. AOSP never claimed that those rules should be used for your own android project, just for contributing to the project. Just like you wouldn't use the Linux Kernel Coding Style for your app that runs on linux, you shouldn't use the AOSP coding style for your apps that run on Android. And if you try to argue for it on an app you work on, that can be fine if you find benefit; but don't give the argument that you have to because it's an Android project. That just doesn't make any sense.