Angular-styleguide: соглашение о публичных / частных членах

Я полностью согласен с этим. Извините, я пропустил эту часть.

Прохладный.

И я думаю, что у вашей проблемы есть некоторая перспектива, которую важно добавить в руководство, поэтому я открою ее снова. :)

Я хотел бы добавить в руководство часть, касающуюся их именования. Если вы спросили, то и кто-то другой тоже.

Какой смысл использовать подчеркивание в именах частных функций, а не в членах? Разве это тоже не личное? Или подчеркивание придает другой смысл самой функции?

Теперь, когда вы упомянули об этом, я предпочитаю подчеркивание и для атрибутов. У вас может быть что-то вроде:

private _foo: string;

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

get foo() { return this._foo; }

Конечно, с более сложными сеттерами и геттерами.

да, опечатка

Лично мне не нравятся подчеркивания ... но поскольку в javascript нет ни частных, ни публичных, очень полезно иметь способ их различать. Поэтому я их использую

ОБНОВЛЕНИЕ: я имел в виду ES5 ... с Typescript, который я не использую; подчеркивание

Как вы думаете, будет ли путаница, если будет опущено подчеркивание?

TypeScript / JavaScript не имеет настоящих частных переменных, а использование классов означает, что у нас даже меньше возможностей скрывать переменные, чем в предварительном классе JavaScript. У нас есть только условное обозначение «_», которое нас спасает.

Основное значение условного обозначения «_» состоит в том, что он кричит « Не трогай! ». При отладке JavaScript это все, что нам нужно.

Когда люди видят в отладчике something.foo , они не могут точно знать, является ли этот foo (а) общедоступным и недокументированным или (б) частным. Без надлежащего уведомления они могут ссылаться на это в своем собственном коде. В этот момент разработчик берет на себя обязательство по поддержке.

Когда читатели видят _foo , они должны знать, что это запрещено . Если они ссылаются на _foo они делают это _ на свой страх и риск_. Когда разработчик удаляет его или меняет поведение, не должно быть слез.

В наших документах и ​​примерах частные члены должны начинаться с символа «_». Если мы пренебрегли префиксом приватного символа "_", мы исправим это быстро.

Предположение Уорда состоит в том, что мы будем отлаживать javascript .... некоторым это может показаться странным, но я считаю это отличным планом резервного копирования, если исходные карты не работают так быстро или мы просто хотим более четкого понимания того, что происходит.

Это также отличный визуальный индикатор того, как его использовать.

Все, что сказал Уорд.

Также с ng2 у нас может быть ссылка вроде:

<my-dir #myDir>

и получить доступ к атрибутам внутри. Если у одного из них есть подчеркивание, это означает, что "завтра может сломаться, не делайте этого".

Согласитесь, лучшего способа их различить нет. Это старая школа разработчиков. Ничего не помешало, кроме удобства.

Проблемы с Angular 2 теперь будут попадать в руководство по стилю A2 в репозитории angular.io.

Обратите внимание, что текущий стиль кода Angular (правило 03-04) был изменен по сравнению с предложением @johnpapa здесь и теперь советует НЕ использовать подчеркивание для частных переменных:

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.

Это обратное тому, что предлагается в этом выпуске.

Когда я впервые прочитал этот выпуск, мне показалось, что я обнаружил разницу, но обновленное / перевернутое правило соответствует рекомендациям по кодированию машинописного текста (правило № 6 для имен).

Я думаю, что аргумент TypeScript tooling мог поколебать Джона. Видя, как он так свободно владеет Gulp, он, возможно, решил, что отсутствие рабочих файлов .map для отладки - это просто неработающая ситуация, которую следует исправить напрямую, вместо того, чтобы исправлять ее в своем коде, засоряя его символами подчеркивания: P.