Using underscores in Java variables and method nam

Question

Even nowadays I often see underscores in Java variables and methods, an example are member variables (like "m_count" or "_count"). As far as I remember, to use underscores in these cases is called bad style by Sun.

The only place they should be used is in constants (like in "public final static int IS_OKAY = 1;"), because constants should be all upper case and not camel case. Here, the underscore should make the code more readable.

Do you think using underscores in Java is bad style? If so (or not), why?

Answer 1

Here's a link to Sun's recommendations for Java. Not that you have to use these or even that their library code follows all of them, but it's a good start if you're going from scratch. Tool like Eclipse have built in formatters and cleanup tools that can help you conform to these conventions (or others that you define).

For me, '_' are too hard to type :)

Answer 2

I don't think using _ or m_ to indicate member variables is bad in Java or any other language. It my opinion it improves readability of your code because it allows you to look at a snippet and quickly identify out all of the member variables from locals.

You can also achieve this by forcing users to prepend instance variables with "this" but I find this slighly draconian. In many ways it violates DRY because it's an instance variable, why qualify it twice.

My own personal style is to use m_ instead of _. The reason being that there are also global and static variables. The advantage to m_/_ is it distinguishes a variables scope. So you can't reuse _ for global or static and instead I choose g_ and s_ respectively.

Answer 3

I think any style that breaks a language's own style guidelines (without due reason) is ugly and therefore "bad".

No doubt the code you've seen was written by someone who used to work on a language where underscores were acceptable.

Some people just cannot adapt to new coding styles...

Answer 4

The reason people do it (in my experience) is to differentiate between member variables and function parameters. In Java you can have a class like this:

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

If you made the member variable _var1 or m_var1, you wouldn't have the ambiguity in the function.

So it's a style, and I wouldn't call it bad.

Answer 5

If you have no code using it now, I'd suggest continuing that. If your codebase uses it, continue that.

The biggest thing about coding style is consistency. If you have nothing to be consistent with, then the language vendor's recommendations are likely a good place to start.

Answer 6

Personally, I think a language shouldn't make rules about coding style. It is a matter of preferences, usage, convenience, concept about readability.
Now, a project must set coding rules, for consistency across listings. You might not agree with these rules, but you should stick to them if you want to contribute (or work in a team).

At least, IDEs like Eclispe are agnostic, allowing to set rules like variable prefixes or suffixes, various styles of brace placement and space management, etc. So you can use it to reformat code along your guidelines.

Note: I am among those keeping their old habits from C/C++, coding Java with m_ prefixes for member variables (and s_ for static ones), prefixing booleans with an initial b, using an initial uppercase letter for function names and aligning braces... The horror for Java fundamentalists! ;-)
Funnily, that's the conventions used where I work... probably because the main initial developer comes from MFC world! :-D