Android source code and many Android open-source apps and libs use m prefix for member fields and s prefix for static member fields:
private static boolean sStarted;
private long mTimestamp;
I personally dislike this, because it looks ugly and it’s redundant – my IDE already uses different color and formatting for local, member and static member variables.
What’s closest to truth?
- It’s a good practice.
- It’s a bad practice but you should use it anyway in order to be consistent with the majority of Android code out there.
- It’s a bad practice and you shouldn’t use it.
2
The naming convention you described is very much like (if not the same as) system hungarian notation. There has been a lot of discussion about it here (Struggling not to use Hungarian notation), and obviously it is redundant.
Thus the answer to your first question, No, it isn’t a good practice.
The second question is a little harder. In case you work on an existing code-base with that convention, its better to keep using it.
I personally wouldn’t use this convention when creating something from scratch, even if I use libraries with that very convention. That practice is really redundant and you gain nothing from it taking into account the capabilites of IDE-s. I would instead keep consistent and accurate names in my own application, which would make it clear enough.
4
This is an old question, but I’m answering to disagree with the accepted (and only) answer.
I’ve been a Java programmer for about fifteen years, and I’ve been doing it professionally and intensively for about three years. I initially resisted the mMember convention for all the abstract reasons commonly cited. But the longer I stared at Java code, the more this convention grew on me. I started using it myself a few months ago.
For one thing, it is not entirely redundant. Even with modern syntax highlighting, the convention makes it easier to immediately recognize that an identifier is a member field. Especially at 3 A.M.
And many of the arguments against Hungarian notation are actually arguments against Systems Hungarian notation, in which the warts identify the type of the variable. This is indeed redundant in a strongly-typed language like Java. But there’s a good argument to be made for Application Hungarian, in which the warts encode the scope and usage. Googling these two terms will turn up several articles.
Your second point is closest to the truth. I would argue that it is not bad practice at all, for the reasons given above. But I think we can leave that argument aside and say that you should do it solely on the basis of convention. The reasons for this are both practical and social.
The Java community has very strong naming conventions. They become ingrained to the point where code that does not follow them becomes hard to read. If you don’t use the mMember convention, you can bet that some maintenance programmer who comes after you is going to refactor all your identifier names.
And the social aspect is that not abiding by Java naming conventions immediately flags you to your peers as not a real Java programmer. “Watch out for this guy. He probably doesn’t even know what a memory model is.” (And they’re usually right…)
7