3

Why is it bad to start a variable name with a dollar sign in C++/Java and similar such as in PHP?

Edit: Are there any risks?

wattostudios
  • 8,666
  • 13
  • 43
  • 57
Johanna
  • 31
  • 1
  • 2

8 Answers8

6

In Java, using $ in variables is legal but definitely a bad idea.

If you do this, there is a risk that you will accidentally use a name that collides with a name that is used by the compiler itself, or by some code generator. The result will be unexpected compile or runtime failures that could be particularly difficult to diagnose ...

There's also a potential risk that your (mis-)use of $ will cause problems in future versions of Java. The Java compiler / runtime's use of $ may change in a future, causing your abusive code to fail.

Just don't do it. Or at least, don't do it unless you are writing a generator ... and you know what you are getting yourself into.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
5

In C++, it's non-portable. The only characters the standard says (section [lex.name]) must be acceptable to begin an identifier are uppercase and lowercase letters and underscore.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
3

Java allows the dollar sign to begin identifiers, but recommends that it only be used for mechanically generated code. (see here)

It appears that in C++ identifiers may be able to use dollar signs as an extension, but it's not part of the standard.

icktoofay
  • 126,289
  • 21
  • 250
  • 231
2

For java from this post

The convention, however, is to always begin your variable names with a letter, not "$" or "_". Additionally, the dollar sign character, by convention, is never used at all. You may find some situations where auto-generated names will contain the dollar sign, but your variable names should always avoid using it. A similar convention exists for the underscore character; while it's technically legal to begin your variable's name with "_", this practice is discouraged.

I don't think there are any risks/side effects; it's just discouraged.

Xeo
  • 129,499
  • 52
  • 291
  • 397
Bala R
  • 107,317
  • 23
  • 199
  • 210
2

In Java $ is used in inner class names, and probably some "synthetic" method names as well. Basically any code that the compiler has to generate to handle inner classes will have a $ in it. Using the $ would, at the very least be confusing because of that. You should, generally speaking, never need to see a $ in a variables/method/class name in Java.

TofuBeer
  • 60,850
  • 18
  • 118
  • 163
1

Because the JLS 8 3.8 says so:

The $ sign should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.

And you can really generate code that fails to compile, e.g. on Oracle JDK 1.8.0_45:

public class Assert {
    static final boolean $assertionsDisabled = false;
    public static void main(String[] args) {
        assert System.currentTimeMillis() == 0L;
    }
}

The problem is that javac generates a field $assertionsDisabled to implement assert, which conflicts with our field.

See also: https://stackoverflow.com/a/29439538/895245

Community
  • 1
  • 1
Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
0

Because in both C++ and Java doing so would be a syntax error (in the case of C++) or bad style (in the case of Java). Neither of these languages need variables to be so indicated, and doing so is wrong. Starting variables with a special character (like '$') makes things a lot easier for the language system (which is important for interpreted languages like PHP), but makes life much harder for the programmer, because they have to type in all those '$' characters. So most languages (even most interpreted languages) don't require them.

  • I'm pretty sure `$` is a legal variable name in Java. Doesn't have to be in C++, although the implementation can allow non-standard characters to be used (it's not like C++ gives `$` any other meaning). – Ben Voigt Apr 30 '11 at 23:30
  • In Java it is perfectly legal to start your variable names with a $, but the convention is that that character is not used at all. – Arjan Apr 30 '11 at 23:32
  • @Ben I know little of Java, but I've never seen any Java code that begins variables with '$' (or includes them). –  Apr 30 '11 at 23:32
  • In C++, an implementation is required to issue a diagnostic if an variable name contains a `$`. (In other words, using a `$` is a diagnosable error.) – James Kanze Apr 30 '11 at 23:34
  • @James: Is there a rule that says this? The latest draft only mentions the dollar sign in conjunction with numeric formatting (currency) and regular expressions (end-of-string anchor). It appears that `$` could be an "implementation-defined character" allowed to appear in an identifier by `[lex.name]`. – Ben Voigt Apr 30 '11 at 23:36
  • @Ben: "Implementation-defined character allowed in [lex.name]" depends what standard you're talking about. My copy of C++03 allows digits, letters, underscore, and *universal-character-name*. The dollar sign doesn't fall into one of the ranges specified in Annex E. C++0x will allow other implementation-defined characters, but until then it's a grammatical error and so a C++03 standard-conforming compiler has to diagnose. – Steve Jessop Apr 30 '11 at 23:54
  • @Ben The C++03 standard clearly specifies all legal characters in an indentifier. The "implementation-defined character" is a change, and I'm not quite sure what it is supposed to mean: could `+` be an "implementation-defined character" in this context, and `a+` thus become a single token (making an expression like `a+b` illegal)? (Think I'm going to have to raise another DR.) – James Kanze Apr 30 '11 at 23:59
  • @Steve Do you have a ref for C++0x allowing other characters? –  May 01 '11 at 00:02
  • @unapersson: 2.11 [lex.name] in the current draft. – Steve Jessop May 01 '11 at 00:28
0

The main reasons I can think of are here. In Java, the inner class names are created with $ sign. Also, the $ sign is used for env variables in most of the Oses, so it would be confusing and may intervene the system defined variables.

user229044
  • 232,980
  • 40
  • 330
  • 338
San
  • 11
  • 1