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() {

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.


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"

  • 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. – Paul Oct 25 '17 at 0:50
  • 1
    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. – CodingYoshi Oct 25 '17 at 1:20
  • 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. – Walfrat Oct 25 '17 at 14:25
  • 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. ;) – besc Oct 25 '17 at 19:25

Perhaps it's not as common as you might expect because javascript doesn't exaclty 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:



or documentation such as


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

TypeScript/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.

  • 1
    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. – Derek Elkins Oct 25 '17 at 1:15
  • @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. – user949300 Oct 25 '17 at 5:24

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).


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.

  • 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 – jitbit Oct 25 '17 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.