7

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.
fhucho
  • 243
  • 2
  • 8
  • 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 06 '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. – Lovis Feb 16 '15 at 07:31

2 Answers2

7

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.

Community
  • 1
superM
  • 7,363
  • 4
  • 29
  • 38
  • 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. http://android-developers.blogspot.co.uk/2012/05/using-dialogfragments.html . I see you opted for the Reverse Hungarian! – JohnMark13 Sep 06 '13 at 21:36
  • 1
    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 07 '13 at 08:13
  • 3
    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 07 '13 at 14:52
  • https://jakewharton.com/just-say-no-to-hungarian-notation/ – jeprubio May 08 '19 at 10:22
3

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

Kevin Krumwiede
  • 2,586
  • 1
  • 15
  • 19
  • 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.** – Lovis Feb 16 '15 at 07:35
  • But I don't have 15 years of experience yet, so I might still see one someday. ;-) – Lovis Feb 16 '15 at 07:37
  • @Lovis as an Android dev, I've worked with codebases that use it. I believe it's much more common in enterprise Java, but that's hardly a recommendation. In fact you can see it in Android SDK source code - although that's a legacy thing in my view and not an example to follow. Personally I don't like the convention and agree with your argument: this prefix is just a painkiller. It's easier to take it than to tackle the real cause of the pain (typically overly complex codebase). – Konrad Morawski Oct 17 '16 at 11:16
  • 2
    *"not abiding by Java naming conventions immediately flags you to your peers as not a real Java programmer..."* - that's a really blunt statement Kevin. Which naming conventions? For instance Google style guide explicitly says it's a no-no, see https://google.github.io/styleguide/javaguide.html "In Google Style special prefixes or suffixes, like those seen in the examples name_, mName, s_name and kName, are not used". – Konrad Morawski Oct 17 '16 at 11:18
  • @KonradMorawski I'm proposing that adherence to mainstream conventions correlates strongly with code quality. I'm not proposing a causal relationship between these things, of course; I think both are the result of experience. And there are certainly variations in conventions at large companies. But Google's bucking of convention is an example of the correlation I'm talking about. They seem to be completely clueless about how to manage issues, many Android APIs show signs of very little thought having gone into them, and the Google Maps API team doesn't know how to identify a memory leak. – Kevin Krumwiede Oct 17 '16 at 18:38
  • I don't know why one would dismiss Google's modern style guide as non-mainstream, and it's a bit of a stretch to imply that memory leaks in Google Maps are a result of not using "m" prefixes in the codebase, unless you have something to substantiate this allegation. For all I know they may actually be used over there, and then what :) Because Google isn't 100% consistent, e.g. the prefixes are prevalent in Android SDK sources (I see that as a legacy thing). We may disagree on that, but it's good to expose beginners to differing points of view so they can make their own mind. – Konrad Morawski Oct 19 '16 at 19:02
  • And I'm not even saying there's no correlation between the bugs ratio and the convention. Since it's more dated, I'd expect it to be followed more often in old codebases that have reached maturity longer ago. This would be sort of circumstantial though and doesn't indicate this is good practice. – Konrad Morawski Oct 19 '16 at 19:12