Why is it uncommon (is it?) to use _ (underscore) in JS private vars?

Question

Coming to JavaScript from C# and C/C++ world, I'm used to decorating my private members with underscore.

But a couple of JS devs I know have told me it's not common in JS world, and my code looks "weird" to them. I got intrigued and interviewed about 4-5 more JS devs and they all confirmed.

Just to be clear, her's my code:

var myObject = new myClass("some value");
function myClass(param) {
 var _privateVar = param;
 this.publicMethod = function() {
 alert(_privateVar);
 }
}

Now my questions are:

1. Is this true? Should I stop writing code like this - note, I ask only in the scope of hiring, just wanna be sure that newcomers won't find our existing code "weird"

2. If it is true, is there any explanation? Or it sorta "historically" happened? Not trying to start a flame-war or anything, just curious, I'm fine with dumping my old habits.

UPDATE

OK, maybe I shouldn't call it "private" variable b/c it's actually a "local" variable... But you know what I mean. I need to be able to quickly distinguish variable's scope, by simply looking at it. How "local" are the vars? Are they local to publicMethod or to the whole myClass? That's the reason of using underscore, not the actual "privacy"

• Paul: Just as an aside, you really should read up on JS prototypal inheritance. While yes, you can 'fake' classes the way you're doing it; that way lies madness. There are a LOT of cases where you'll think you're doing something like a class in C# or C++ that simply won't work that way in JS.
• CodingYoshi: Even in C# the convention on some teams is to not use underscore but some teams prefer to use it. The underscore is very common in vb.net because it is case insensitive so distinguishing between a local variable employeeId and a private field is done through making the private field _employeeId. But yes in JavaScript this is not the convention because there are no privates per-se in JavaScript but achieving privacy is possible.
• Walfrat: Personnaly I prefer using this which however make my variable public but at least always shows that the variable is bound to my object whatever the visibility. It is consistent with what I do with others languages. If some people want to mess with my code, they could monkey patch it aniway. It's their problem if they mess up using things they shouldn't, not mine.
• besc: As a C++ side note: Names with leading underscores (also multiple underscores anywhere in the name) are better avoided there too, because under some not quite so trivial circumstances such identifiers are reserved for the (language/stdlib) implementation. I imagine debugging name clashes between your own code and the stdlib isn’t exactly the definition of a fun week at work. ;)
• Berin Loritsch: The _ prefix is common in C# because of Microsoft coding standards. I remember knock down arguments whether Java private members should be prefixed in any way. Many OOP languages don't have that as a coding style. However, the languages I use these days, it's a stylistic choice. I personally don't like it, but I don't have heartburn if I'm contributing to a project that does use that convention. I just adapt to the team's conventions.

Answer 1

Perhaps it's not as common as you might expect because javascript doesn't exactly have private variables...

The use of the _ prefix is something that non-javascript developers bring in from other languages, but it's not conventional and might cause some confusion.

It's not altogether unheard of to use the _ prefix, though, as you can see in other SO questions such as:

https://stackoverflow.com/questions/34418012/how-to-work-with-private-variables-in-es6

https://stackoverflow.com/questions/22156326/private-properties-in-javascript-es6-classes

or documentation such as

https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Contributor_s_Guide/Private_Properties

There are also some very well respected developers who advocate for using the _, an example of which is this comment by Ward Bell:

JavaScript doesn't have true private variables and the use of classes means that we have even less of an ability to hide variables than in pre-class JavaScript. We have only the '_' convention to save us.

The primary value of the '_' convention is that it shouts "Do not touch!". When debugging the JavaScript it's all we have to go on.

When people see something.foo in the debugger, they can't know for certain if that foo is (a) public and undocumented or (b) private. Without adequate notice, they feel free to reference it in their own code. In that moment, the developer incurs a support obligation.

When readers see _foo, they should know it is off limits. If they reference _foo they do so at their own risk. There must be no tears when the developer removes it or changes its behavior.

In our docs and samples private members should begin with ''. Where we have neglected to prefix a private with '', we correct that quickly.

• Derek Elkins left SE: If you decide what you can reference by looking in a debugger, you deserve what you get. "Public and undocumented" seems like a bit of a contradiction especially here where the significance of "public" seems to be "supported". "Supported and undocumented" seems even more like a contradiction.
• user949300: @Derek Elkins in Ducktyped languages like JS, sometimes the only way to find out what you can reference is to look with a debugger, or console.dir() which is pretty much the same. A lot of JS modules have documentation which is lacking or thin.
• candied_orange: Python doesn't exactly have private variables either. Yet it's convention is to use the _ prefix to signal to other coders that a variable should be treated as private. Their mantra is "we're all adults here". A better explanation is that JavaScript isn't Python.

Answer 2

In your example, _privateVar is not a private variable. It is a local variable. After myClass exits, it is available to nobody (unless in a closure). There is no such thing as a private variable in Javascript.

Local variables are the most common^* and it seems a little nuts to mark all of them with underscores. Also, all function arguments have local scope as well; are you going to mark all of your parameters with underscores? That would be hideous.

If you wish to make clear the difference between local and global variables, I suggest using window to mark the global variables (since that is where they actually live).

Thus

var myVariable = "Local value";
window.myVariable = "Global value";

^* If you find that in your code global variables are more common than local variables, I'm pretty sure that you are doing it wrong.

• jitbit: Ok, maybe naming it "private" is not correct, but adding underscores help my quickly see how "local" is the variable. Is it local to publicMethod or to myClass? I find underscoring works great