Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

7
  • 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. Commented Feb 16, 2015 at 7:35
  • But I don't have 15 years of experience yet, so I might still see one someday. ;-) Commented Feb 16, 2015 at 7: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). Commented Oct 17, 2016 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 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". Commented Oct 17, 2016 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. Commented Oct 17, 2016 at 18:38