What's the catch to create _names _of _fields _like _these in java?

Question

From time to time I see something like this:

class Clazz {

   private int _goodName;

   private int _anotherGoodName;

   ...
}

I don't get it. It's hard and unusual to read such code. What are the pros?

Answer 1

It's a naming convention used by some people to indicate "these are private variables".

Personally I'm not a fan as I think you can leave off the underscore and achieve the same result, but to each his own. I think it may have it's roots in pre-IDE days when you might be viewing a method and the visibility/ownership of certain variables is not always clear.

Answer 2

The examples of members and methods prefixed with an underscore I've seen use the convention to indicate that you shouldn't touch that member or method, when you can't make it private. I read it as 'here be dragons', never had a reason to use it myself.

An example is the _jspService() method in servlet development. Check out the linked JavaDocs.

Answer 3

It's just a matter of preference. Some people like to add a '_' to all private members variables of a class, other's dont. I personally do not like it but again it's preference.

Answer 4

Naming conventions are all about what's comfortable for the person writing the code to read/replicate (though they should be about whats easy for everyone to read)

I have a friend who uses this convention along with something like:

private int m_myVariable;

for all of his fields etc. It denotes it as a member of the particular class you're looking in but it gets very very annoying to read if you don't do the same.

Answer 5

If it is a likely scenario that you could have a member variable, a property and a parameter all refer to the same thing, it makes perfect sense to distinguish:

private string _myVariable;
public MyClass(string myVariable)
{
    //do stuff.
    _myVariable = myVariable;
}

public string MyVariable
{
    get
    {
         return _myVariable;
    }
}

Answer 6

I used to use these conventions in my code:

• Non-final, static fields begin with an underscore.

  private static SomethingOrOther _goodName;
  

• Parameters end with an underscore.

  public void doSomething(Object goodParam_, String stringToo_) {
  }
  

And while you may consider it hard to read in the declaration of the variable, the point is to make sure they pop when reading the code in which they're used and to ensure that they are always different than any non-static fields, parameters and locally defined variables.

Another benefit of standards like this, i think, is when others come along to modify the code, they can quickly identify static fields and parameters which makes comprehension of the code happen more readily rather than having to always refer back to definitions.

I don't generally consider a convention for instance fields because access to them is almost exclusively through s/getters.

I've moved away from this with Java code, preferring instead to have my IDE always fully qualify with this for instance fields and with the class name for static fields and always using final on every variable that doesn't change, even method parameters. The interesting thing about going this route is that it encourages good naming practice, at least for me, because i like my variables to read nicely when prefixed with this or the class name.