Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

  1. It's a good practice.
  2. It's a bad practice but you should use it anyway in order to be consistent with the majority of Android code out there.
  3. It's a bad practice and you shouldn't use it.
share|improve this question

closed as primarily opinion-based by durron597, Ixrec, enderland, Snowman, GlenH7 Aug 19 at 15:16

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

4  
Good question. I had to do a fair bit of Android development lately and I too wondered why Java development was going quasi-Hungarian. –  JohnMark13 Sep 6 '13 at 20:41
    
They probably did this in the android SDK because the classes are so amazingly huge, that it was actually adding some value. It was taken into the tutorials and spread into the world from there. –  L. Möller Feb 16 at 7:31

2 Answers 2

up vote 5 down vote accepted

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.

share|improve this answer
1  
But, any idea why they did it? I went to the Android developers site, opened the first article and bam, it uses it. Like you say I just don't do it, but I find it odd. android-developers.blogspot.co.uk/2012/05/… . I see you opted for the Reverse Hungarian! –  JohnMark13 Sep 6 '13 at 21:36
    
Note this is not full blown Hungarian Notation, it only distinguishes fields by its kind. I imagine it may be useful in constructors and setters (mFoo = foo; rather than this.foo = foo;). It also makes you less reliant on semantic coloring which not every color theme/IDE offers. –  Xion Sep 7 '13 at 8:13
2  
The font changes provided by IDE's are more subtle than this convention and so easier to miss. Additionally not all programming is done in IDE's. Therefore I think it's an overstatement to say that the convention is redundant flat-out. I suspect these are the reasons that the Android team has used this naming convention. –  MikeFHay Sep 7 '13 at 14:52

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...)

share|improve this answer
    
No java/android Dev I ever worked with used the m* convention. Some used an underscore, but for me the whole point is, that your classes and methods shouldn't be so big that you can't tell the difference between a member and a local at the first glance. –  L. Möller Feb 16 at 7:35
    
But I don't have 15 years of experience yet, so I might still see one someday. ;-) –  L. Möller Feb 16 at 7:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.