Angular-styleguide: convention around public / private members

I totally agree with that. I am sorry, missed that part.

Cool.

And I think your issue has some perspective that is important to add to the guide, so i will reopen it. :)

I'd like to add the part about naming of these to the guide. If you asked, then so will someone else.

What's the point of using underscore in private function names and not members as well? Isn't it also private? Or, does underscore give a different meaning to the function itself?

Now that you mention it, yeah, I prefer underscore for attributes as well. You can have something like:

private _foo: string;

@Input()
set foo(value) { this._foo = value; }

get foo() { return this._foo; }

With more complex setter and getters of course.

yes, typo

I don't like underscores personally ... but since there is no real private nor public in javascript, it is very helpful to have a way to differentiate them. So I use them

UPDATE: i was referring to ES5 ... with Typescript I don;t use underscore

Do you think that there will be confusion if underscore is omitted?

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.

Ward's assumption is that we would be debugging the javascript .... to some that may seem odd, but I see it as a great backup plan if sourcemaps do not work so hot or if we just want a clearer understanding of what is happening.

It is also a great visual indicator of how to use it.

All what Ward said.

Also with ng2 we can have a reference like:

<my-dir #myDir>

and access the attributes inside. If one of them has an underscore, it is signal of "this could be broken tomorrow, don't do it"

Agree, no better way to distinguish them. It's an old school for developers. It's not hurt anything except convenience.

Angular 2 issues will now go to the A2 style guide in the angular.io repo

Please note the current Angular codeStyle (rule 03-04) has been changed compared to @johnpapa's suggestion here and now advises NOT to using an underscore for private variables:

Avoid prefixing private properties and methods with an underscore.
- Why? Follows conventional thinking for properties and methods.
- Why? JavaScript lacks a true private property or method.
- Why? TypeScript tooling makes it easy to identify private vs. public properties and methods.

So this is the reverse of what is suggested in this issue.

When I first read this issue this I thought I had found a difference, but the updated/flipped rule IS in line with the typescript coding guidelines (rule nr 6 for names).

I think the TypeScript tooling argument might have swayed John. Seeing as he is so fluent in Gulp, he might have decided that not having working .map files for debugging is just an unworkable situation, that should be remedied directly, instead of fixing it in your code by littering it with underscores :P.