Why should instance variable names not start with '_' (underscore)?

[Kerry Kimbrough]

Sun's Code Conventions for the Java Programming Language say that
instance variable (class data member) names should not begin with '_'
(underscore). But why? What is the rationale for this rule?

Within my group, some say this is to avoid conflict with secret
instance variables introduced by the compiler or JVM. But no one
claims to have actually observed this. Moreover, there is a lot of
published code that adopts a contrary convention of *always* marking
private data member names with a leading '_'. So the "secret conflict"
story smells like a superstition left over from the early days of C
compilers/linkers.

Anyone know the real story?

Regards,
Kerry

 

[Sasha]

Within my group, some say this is to avoid conflict with secret
instance variables introduced by the compiler or JVM. But no one
claims to have actually observed this. Moreover, there is a lot of
published code that adopts a contrary convention of *always* marking
private data member names with a leading '_'. So the "secret conflict"
story smells like a superstition left over from the early days of C
compilers/linkers.

Well, I've prefixed instance variables with underscores for 5 years and
never had a problem.

Of course, my production code could now be a ticking bomb...

- Sasha.

 

[Tony Morris]

Well, I've prefixed instance variables with underscores for 5 years and
never had a problem.

Of course, my production code could now be a ticking bomb...

- Sasha.

Because it's a violation of convention, and makes it difficult for others,
who follow convention, to read your code.
That is enough justification NOT to perform such an obscene act.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Ryan Stewart]

Sun's Code Conventions for the Java Programming Language say that
instance variable (class data member) names should not begin with '_'
(underscore). But why? What is the rationale for this rule?

Within my group, some say this is to avoid conflict with secret
instance variables introduced by the compiler or JVM. But no one
claims to have actually observed this. Moreover, there is a lot of
published code that adopts a contrary convention of *always* marking
private data member names with a leading '_'. So the "secret conflict"
story smells like a superstition left over from the early days of C
compilers/linkers.

Anyone know the real story?

Regards,
Kerry

I can't speak to the compiler or JVM introducing variables, but certainly
when JSPs are converted to servlets, there are variables created behind the
scenes that start with an underscore. The names are odd enough, though, that
you're unlikely to hit on them by accident. Those that advocate using a
leading underscore in the naming of local variables and/or method parameters
are carrying on a tradition of C programmers. It has nothing to do with
superstition. It has to do with hiding variables. I'm by no means current in
any of the C languages, but I do know that in at least some versions if you
called the equivalent of a local variable by the same name of the equivalent
of a class or instance variable, then said class/instance variable is hidden
and not accessible until you are out of scope of the local variable.
Therefore, when passing parameters and declaring local variables in C, if
there would be a naming conflict, the common practice was to prefix it with
an underscore or, I believe, "m_", which would allow access to both
variables. In Java, this is unnecessary because of the availability of the
"this" keyword. In all likelihood, this "published code" that you cite was
written by C programmers who don't want to give up their old practices.
Whether there is a "good" reason for having this standard, I couldn't really
say. But you could say the same of many of Java's coding standards.
Standards aren't always meant to separate "good" and "bad" code. They're
just standards. They're there so everyone in the world (who cares about such
things) will code the same way and be able to easily read code written by
others who follow the same standard.

 

[TT \(Tom Tempelaere\)]

I can't speak to the compiler or JVM introducing variables, but certainly
when JSPs are converted to servlets, there are variables created behind the
scenes that start with an underscore. The names are odd enough, though, that
you're unlikely to hit on them by accident. Those that advocate using a
leading underscore in the naming of local variables and/or method parameters
are carrying on a tradition of C programmers. It has nothing to do with
superstition. It has to do with hiding variables. I'm by no means current in
any of the C languages, but I do know that in at least some versions if you
called the equivalent of a local variable by the same name of the equivalent
of a class or instance variable, then said class/instance variable is hidden
and not accessible until you are out of scope of the local variable.
Therefore, when passing parameters and declaring local variables in C, if
there would be a naming conflict, the common practice was to prefix it with
an underscore or, I believe, "m_", which would allow access to both
variables. In Java, this is unnecessary because of the availability of the
"this" keyword. In all likelihood, this "published code" that you cite was
written by C programmers who don't want to give up their old practices.
Whether there is a "good" reason for having this standard, I couldn't really
say. But you could say the same of many of Java's coding standards.
Standards aren't always meant to separate "good" and "bad" code. They're
just standards. They're there so everyone in the world (who cares about such
things) will code the same way and be able to easily read code written by
others who follow the same standard.

In C++, any identifier starting with an underscore followed by a capital
charachter, or any identifier starting with two underscores is reserved.
Making use of such identifiers could result in undefined behaviour. The
rationale is that such identifiers are reserved for implementation (eg STL,
....).

I can't speak for C90 or C99 standards.

 

[Collin VanDyck]

Sun's Code Conventions for the Java Programming Language say that
instance variable (class data member) names should not begin with '_'
(underscore). But why? What is the rationale for this rule?

Within my group, some say this is to avoid conflict with secret
instance variables introduced by the compiler or JVM. But no one
claims to have actually observed this. Moreover, there is a lot of
published code that adopts a contrary convention of *always* marking
private data member names with a leading '_'. So the "secret conflict"
story smells like a superstition left over from the early days of C
compilers/linkers.

My personal opinion is that Java's this. syntax is much easier to understand
than '_' or 'm_'.

'this.' is completely clear and unambiguous. There is no wonder about
whether or not it is an instance variable, as it is enforced by the
compiler.

Also, for some reason, I don't like underscores in my code at all. I like
the mixedCaseNaming of variables. For me, it's much easier to read.

-CV

 

[Chris Smith]

Sun's Code Conventions for the Java Programming Language say that
instance variable (class data member) names should not begin with '_'
(underscore). But why? What is the rationale for this rule?

Within my group, some say this is to avoid conflict with secret
instance variables introduced by the compiler or JVM. But no one
claims to have actually observed this.

It's not the case. There is a character reserved in Java for auto-
generated identifiers, but it's '$' rather than '_'.

The reason is, simply, that in a language with compiler-enforced
visibility constraints and smart editors that keep you advised of them,
there's no reason for dimpling variables to mark them as intended only
for internal use... which is exactly what '_' was always used for.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation