Here http://source.android.com/source/code-style.html#follow-field-naming-conventions it is stated that :
Field Names
- 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.
It also states that :
The rules below are not guidelines or recommendations, but strict rules. You may not disregard the rules we list below except as approved on a need-to-use basis.
I don't like the "m" convention before private or package fields in a class. I really find this uninspired... I mean, if we try to apply good designs, the low coupling of the classes implies having few public fields. actually, in my programs I usually have no public fields, even when I need some I use getters and setters...
So, why should I be forced to have almost all my fields in the program with an "m" in front of them? wouldn't be easier to have the few public fields, if there are any, with some "g" in front or something? or just use setters and getters as beans suggest? this really makes my code harder to read....
Also, following these guidelines, local temp variables used in the methods have no restriction so they could easily be mistaken for public global fields (also without restriction)... this also I find to be wrong, as it is a probable source of mistakes... I understand to have a way of differentiating from fields, but private/protected member fields are the most used in an application, they shouldn't be less "readable".
What do you think? Should I follow the guidelines?
Those coding guidelines are for the Android Open Source Project which is the core Android Platform. You have to follow these guidelines if you want any of your code to be accepted into the core platform. You can do what ever you want in your own applications.
With regards to the guidelines themselves I think they are very reasonable and similar to many standards used in commercial applications. Generally you want to use getters and setters for public field access and you don't want to have global public variables. Only global public constants are ok.
So the short answer is follow them for the Open Source project, decide to follow them in you app.
In regards to getters\setters, it is actually recommended to not use them in Android.
I found this on the "Designing for Performance" page (section: Avoid Internal Getters/Setters): http://developer.android.com/guide/practices/design/performance.html
Bottom line, they infer that instance field lookups are more efficient than Virtual method calls (due to optimizations in the JIT).
I think I will continue to use getters\setters in my code, but this might be an easy way to improve performance (especially for apps that do a lot of data manipulation).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With