• Post Reply Bookmark Topic Watch Topic
  • New Topic

variable name starting with underscore is discouraged  RSS feed

 
radha gogia
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just went through some multiple choice questions and found this question with the below choices,
a) It is not standardized
b) To avoid conflicts since assemblers and loaders use such names
c) To avoid conflicts since library routines use such names
d) To avoid conflicts with environment variables of an operating system

Now , what should be the explanation for answering such question.
 
Liutauras Vilda
Sheriff
Posts: 4923
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
radha gogia wrote:I just went through some multiple choice questions and found this question with the below choices,
a) It is not standardized
b) To avoid conflicts since assemblers and loaders use such names
c) To avoid conflicts since library routines use such names
d) To avoid conflicts with environment variables of an operating system

Now , what should be the explanation for answering such question.


Maybe this question refers to a different language, not Java.
It is not recommended by naming convention, but it is not a problem.
Check this out (last paragraph) > http://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the real reason for those naming conventions in Java® is to avoid confusion between class names and variable names.Start with Java Puzzlers by Bloch and Gafter page 163.

And you find that code will compile and run, which surprised me rather. There are special rules about my use of the word String, and you will see that ¢ is a valid identifier; although it says in the Java Tutorials link that dollar signs are permitted, the compiler actually permits different currency symbols.
You can see that the incorrect use of capital letters has caused you no end of confusion; I think the real reason for those naming conventions is to allow you to disambiguate classes and identifiers. That is why you can have a long being wrapped in a Long object.
Dollar signs are reserved for compiler‑generated names; if you confuse that class even more by adding an anonymous class and do ls/dir you will see it appears as WontCompile$1.class
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Answers b, c, and d each cannot be correct, as none of them is true.

Java variable names exist in a distinct naming space from that used by assemblers and loaders, so no such conflict can exist under any circumstances. Likewise with environment variables (they can have the same names as any Java variables, but exist in a different context that never leaves any ambiguity as to which is which). The Java libraries don't really make variables available outside the context of a class, and the class names all start with an upper-case letter, so there's no problem there.

Now, it is true that there is no standard (that I know of) calling for Java variables to start with an underscore, and the only written standards I know of all discourage it (or ignore it), like the one Liutauras pointed you to, so, because b, c, and d are all false, and a is, at least, not false, I would say the answer is "a" by process of elimination. However, that doesn't really tell you why they are discouraged, and that's a fair question.

One might be able to research this, but I'll give you my own personal view on it, as a result of being a programmer in several languages for quite a long time.

In the early days of programming languages, case didn't matter. That is, if your language let you use two cases at all (and many limited you to upper case for everything, like good old FORTRAN), the case you used didn't make any difference. Thus, if you called a variable, "RATEOFPAY," or "rateofpay" you were referring to the same variable. But that's hard to read, so people used the underscore (which didn't appear much in computer languages for any other reason) to separate out the words, so you have a variable called "RATE_OF_PAY," or "rate_of_pay." Much easier to read, eh?

Now, in some languages (like good old C), variables can be made available to an entire program. These so-called "global" variables can be named like any other, but it can be confusing when reading code if you don't know if a variable is strictly local to a routine, or might be global to your application. So, some (not all) programmers adopted conventions to help identify globals. One convention I saw was to prefix globals with the underscore, so "_counter" was a self-evident global, while "counter" was probably local to a routine.

That's when things actually got messier, rather than neater, because not everyone used the same convention. Further, to avoid conflicts with libraries that did have global variables your program could access, some (not all) programmers began doing other things, like using two underscores to prefix library globals, on the theory that no one would do that in their application code. So, library programmers could name a global variable "__counter," and feel safe that you'd never name one that yourself, and no conflict would ever come up.

Problem was, not everyone did this the same way. I've seen code where the underscore marked a local variable, a class variable, and, of course, a global variable. A convention is useless (or worse) if it isn't reliable, and this whole mess with underscores has never (in my experience) been reliable.

Then, along came Java (and other languages), where the case did matter. This meant that "rate_of_pay," and "Rate_of_Pay" were two different variables. Now, while the underscores do mimic white spaces between the words, they make the variable name longer than it has to be and, to many eyes, still kind of odd in appearance. A lot of people adopted "camelCase" as a formatting convention, wherein every word is capitalized, except the first, and you lose the underscores, giving you names like "rateOfPay." The lower-case first letter tells you this is a variable, and the embedded capitals let you easily see which word is which. There being nothing akin, really, to a global variable in Java, there's no need to mark variables with anything that would denote them as being different from any other. Indeed, the whole allegedly self-documenting nature of "Hungarian" notation (if you've heard of that) has arguably been shown to be lacking in value in an object-oriented context, as you're not really supposed to know or care what type a variable's value refers to, beyond that what it refers to must implement the interface(s) you are relying on it for. There being little remaining use for the underscore (you do still see it in static constants, but that's another topic), it pretty much has vanished from variable names, and simply serves no useful purpose as the first character of anything, as, in that location, it merely takes up a character of space on your screen, without conveying any information whatsoever.

That's my view on it, anyway.
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stevens Miller wrote: . . . "_counter" . . . "counter" . . . "__counter" . . .
Brilliant! See MindProd (No 13).

Unfortunately you can mimic a global variable in Java® quite easily
 
Liutauras Vilda
Sheriff
Posts: 4923
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:and you will see that ¢ is a valid identifier


In addition: Java programs are written using Unicode. Its legal to use any Unicode any where in a Java program, including comments and identifiers such as variable names.
Beside that, it is allowed to embed Unicode characters into Java programs using the special Unicode escape sequence \uxxxx, in other words, a backslash and a lowercase "u", followed by four hexadecimal characters.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Unfortunately you can mimic a global variable in Java® quite easily


Quite so, but at least this embeds the global "i" into a namespace "Foo." (Which, I realize, serenely ignores the fact that importing pack.* means "Foo" exists in a shared namespace with every other public class, but, as we learned recently in another thread, even that can be resolved with explicit references.)

(Actually, to really mimic a global that way, wouldn't i have to be static?)
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It probably should be static, yes. I forgot that bit
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:It probably should be static, yes. I forgot that bit

Good try, though, and further proof that (as a brilliant programmer said, over 30 years ago), "the determined Real Programmer can write Fortran programs in any language."
 
Darryl Burke
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
At the risk of drifting even further off topic ...
macho.jpg
[Thumbnail for macho.jpg]
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stevens Miller wrote: . . . "the determined Real Programmer can write Fortran programs in any language."
That article was obviously written by a quiche eater; he says
Your typical Real Programmer knew the entire bootstrap loader by memory in hex.
Hex?Hex?

A real programmer knows the toggles are arranged in THREEs
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Some C and C++ programming environments regard names that start with an underscore as reserved names - you should not use them, because the compiler or supporting libraries use those names for internal things.

This does however not apply to Java.

Still, you shouldn't use names that start with underscores, since this is not according to commonly accepted naming conventions.

The original question does not look like a question that is about Java. When you interpret the question as being about Java, then there is no good anwer - none of the choices is unambiguously true.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:The original question does not look like a question that is about Java. When you interpret the question as being about Java, then there is no good anwer - none of the choices is unambiguously true.


Good observation, Jesper, and a reminder to QuoteYourSources. I agree that none, in the Java context, is unambiguously true, but I think the argument can be made (since I did, in fact, make it ) that b, c, and d are unambiguously false, leaving only a as what the test-writers seem to like to call, "the best answer."

radha, where did this question come from?
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are permitted underscores in package names under special circumstances.
 
Tim Holloway
Saloon Keeper
Posts: 18799
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Disclaimer: this question was also asked on LinkedIn.

The best reason for not starting a variable name with an underscore isn't technical. It's visual. In PL/1, when you didn't have a full printchain, program listings rendered underscores as blank spaces and some people actually coded for that.

I dislike use of "!" as meaning "not" for the same reason, and it's why I often have the following macro in my C/C++ programs:



Java, alas, doesn't allow for that. However Java EL predefines "not" as an alias for the "!" operator.

Skinny little characters are a lot easier to overlook and thus can cause mistakes. Also, a lot of programming languages either enforce or at least encourage that variable names should start with an alphabetic character.

Because of this, Java is one of the languages (like C) where it's customary to make some "special" variables start with an underscore for one reason or another. It may be to provide infrastructure for a paired non-underscore variable. It might indicate something with special properties or to be accessed only in limited ways. It's almost always going to be a private variable. Not because the language demands it, but just because certain conventions above and beyond the demands of the strict language definition are made easier to follow.
 
Stevens Miller
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim, that's an interesting alternative explanation, though I'd have to say that print-chains (How many here know what one of those is? Hold up your hands, unless you need both on your walker .) and PL/1 are at a bit of a far remove from how underscores have been used in C and Java. Still, I suppose anything's possible.

If you like "not" as an alternative to "!", maybe something like this would work for you:
 
Thomas Gard
Ranch Hand
Posts: 51
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Stevens Miller wrote: . . . "the determined Real Programmer can write Fortran programs in any language."
That article was obviously written by a quiche eater; he says
Your typical Real Programmer knew the entire bootstrap loader by memory in hex.
Hex?Hex?

A real programmer knows the toggles are arranged in THREEs


Absolutely! And octal was SUCH a PITA in the PDP-11 days.....OYE....
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!