91

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Georgi
  • 4,402
  • 4
  • 24
  • 20
  • For those using Kotlin, Kotlin recommends using _ for a private property, "If a class has two properties which are conceptually the same but one is part of a public API and another is an implementation detail, use an underscore as the prefix for the name of the private property." Source: (https://kotlinlang.org/docs/coding-conventions.html#names-for-backing-properties) – A-run Apr 07 '21 at 12:08

15 Answers15

151

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.

Tanktalus
  • 21,664
  • 5
  • 41
  • 68
  • 3
    We do use coding conventions without using underscores. Anyway, looking at frameworks and older code, I often saw underscores. The question that consistency rules over convention is clearly to be answerd for consistency but not the point I thought of while asking the question. – Georgi Sep 29 '08 at 21:14
  • 1
    Continuing use of '_' character would be a bad practice. This way of working introduce extra maintenance cost and you would have to inform these exceptional conventions to each new developer who is joining the team. – Halil Mar 02 '17 at 13:54
  • 1
    this is like naming interfaces this way: `ReadableInterface` - absolutely redundant. In modern IDEs you don't need to specify type of variable or its range - colouring and quick jumping does all the work for you. So IMO this is a bad style as you type redundant characters and force people to read it / maintain it. – kiedysktos Jun 12 '17 at 10:20
126
sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();
Anders Sandvig
  • 20,720
  • 16
  • 59
  • 73
  • The question that consistency rules over convention is clearly to be answered for consistency but not the point I thought of while asking the question. Anyway, there are times you should leave old traces, eh? – Georgi Sep 29 '08 at 21:24
  • 2
    If a "conflicting" naming convention is already in use, I think it depends on how much code we are talking about. I wouldn't recommend rewriting thousands of lines of code just to go from old_convention to newConvention, given that the old convention is used consistently. – Anders Sandvig Sep 29 '08 at 21:55
  • LOL! That being said, when code gets pasted in editors that have spellcheck, then the 'misspelled' words are underlined, thereby obscuring the underscore. This is a good reason to not use underscores. Also, Camel case is shorter. Finally, the shift key is easier to use on letters than on the upper row (i.e shift dash '-'). – Tihamer Mar 20 '19 at 17:51
  • @Tihamer Others would argue that the `snake_case` form is easier to read. Especially with short words (1-2 letters), I would definitely argue that this is the case. As for "hard to type", typing a word with lotsOfMixedCaseWithinIt is not precisely convenient either. I'd advocate that it's a matter of what you are used to. In Java though, I say "use the common form" as recommended by the JLS/etc. In Ruby/Python/C, use snake case. And so on... – Per Lundberg Apr 16 '19 at 09:36
37

Rules:

  1. Do what the code you are editing does
  2. If #1 doesn't apply, use camelCase, no underscores
davetron5000
  • 24,123
  • 11
  • 70
  • 98
33

I don't think using _ or m_ to indicate member variables is bad in Java or any other language. In 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 slightly 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 variable's scope. So you can't reuse _ for global or static and instead I choose g_ and s_ respectively.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • 1
    This question was about asking about Java underscores in general, not about asking them only at member variables (though this was an example in the question). – Georgi Sep 30 '08 at 00:01
  • 10
    So you mark me down for commenting on a subset of the question? Seems a bit extreme – JaredPar Sep 30 '08 at 00:01
  • 1
    @JaredPar - you are the only one that gives a good alternative styling suggestion. +1 for that. – djangofan Apr 23 '13 at 20:51
  • 1
    Writing this.foo (or this->foo in C++) would probably be a much clearer way of differentiating locals and fields / member variables. – Kevin Aug 08 '14 at 01:59
7

"Bad style" is very subjective. If a certain conventions works for you and your team, I think that will qualify a bad/good style.

To answer your question: I use a leading underscore to mark private variables. I find it clear and I can scan through code fast and find out what's going on.

(I almost never use "this" though, except to prevent a name clash.)

Christophe Herreman
  • 15,895
  • 9
  • 58
  • 86
  • Like you said, style is very subjective. I tend to use `this` quite liberally to indicate a member variable if I think that it needs attention drawn to it. However, I'm not a zealot about it. – Chris Cudmore Sep 29 '08 at 19:36
6

Using 'm_' or '_' in the front of a variable makes it easier to spot member variables in methods throughout an object.

As a side benefit, typing 'm_' or '_' will make intellsense pop them up first ;)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Nicholas Mancuso
  • 11,599
  • 6
  • 45
  • 47
5

There is a reason why using underscores was considered being bad style in the old days. When a runtime compiler was something unaffordable and monitors came with astonishing 320x240 pixel resolution it was often not easy to differentiate between _name and __name.

ReyCharles
  • 1,772
  • 10
  • 30
Vladimir Miller
  • 51
  • 1
  • 1
5

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

Martin
  • 2,573
  • 28
  • 22
Matt
  • 2,226
  • 16
  • 18
5

  • I happen to like leading underscores for (private) instance variables. It seems easier to read and distinguish. Of course, this thing can get you into trouble with edge cases (e.g., public instance variables (not common, I know) - either way you name them, you're arguably breaking your naming convention:

    private int _my_int;
public int myInt;? _my_int? )

  • As much as I like the _style of this and think it's readable, I find it's arguably more trouble than it's worth, as it's uncommon and it's likely not to match anything else in the codebase you're using.

    Automated code generation (e.g., Eclipse's generate getters and setters) aren't likely to understand this, so you'll have to fix it by hand or muck with Eclipse enough to get it to recognize it.

Ultimately, you're going against the rest of the (Java) world's preferences and are likely to have some annoyances from that. And as previous posters have mentioned, consistency in the codebase trumps all of the above issues.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Steve B.
  • 55,454
  • 12
  • 93
  • 132
  • 3
    Setting up Eclipse to understand your prefix (or suffix) preferences is pretty straight-forward. In _Preferences->Java->Code Style_ there's a table where you can set the variable name conventions for fields, static fields, static final fields, parameters and local variables. All the code generators appear to respect these settings. – metasim Apr 09 '12 at 13:21
4

It's nice to have something to distinguish private vs. public variables, but I don't like '_' in general coding. If I can help it in new code, I avoid their use.

Fry
  • 4,106
  • 9
  • 38
  • 51
3

It's a blend of coding styles. One school of thought is to preface private members with an underscore to distinguish them.

setBar( int bar)
{
   _bar = bar;
}

instead of

setBar( int bar)
{
   this.bar = bar;
}

Others will use underscores to indicate a temporary local variable that will go out of scope at the end of the method call. (I find this pretty useless - a good method shouldn't be that long, and the declaration is right there! So I know it goes out of scope.) God forbid a programmer from this school and a programmer from the memberData school collaborate! It would be hell.

Sometimes, generated code will preface variables with _ or __. The idea being that no human would ever do this, so it's safe.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Chris Cudmore
  • 29,793
  • 12
  • 57
  • 94
  • In your case I use the following: setBar( int aBar) { bar = aBar; } Readable, without this. or _bar ... – Georgi Sep 29 '08 at 21:20
  • That's fair enough, but then aBar shows up in the method signature in the API, and I think it looks messy. – Chris Cudmore Sep 30 '08 at 16:49
  • 1
    I actually ran into a case where autogenerated code matched one of the language keywords, so the best way to avoid this was to prepend a _ at the beginning. – Joe Plante Jan 17 '13 at 20:34
2

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

Joe Ratzer
  • 18,176
  • 3
  • 37
  • 51
  • 1
    I mostly agree with the "do as others do" philosophy when coding, but not as an absolute. I think there is a very strong argument that, given reasonable identifier lengths, that snake_cased_variables are easier to read than CamelCasedVariables. My justification is that reducing cognitive load visually is a small thing, but still useful. People appreciate white space in code, when reading documents, and listening to music. Camel case, I think, is an affront to white space in the name of 'efficiency'. Efficiency for who? – David J. Oct 27 '11 at 16:10
2

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.

2

Personally, I think a language shouldn't make rules about coding style. It is a matter of preferences, usage, convenience, and 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 Eclipse 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 the MFC world! :-D

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
PhiLho
  • 40,535
  • 6
  • 96
  • 134
0

It's just your own style, not a bad style code nor a good style code. It just differentiates our code with the others.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131