Angular-styleguide: convenção sobre membros públicos / privados

Eu concordo totalmente com isso. Sinto muito, perdi essa parte.

Legal.

E acho que seu problema tem alguma perspectiva que é importante acrescentar ao guia, então vou reabri-lo. :)

Eu gostaria de adicionar a parte sobre como esses nomes são nomeados no guia. Se você perguntou, outra pessoa também o fará.

Qual é o objetivo de usar sublinhado em nomes de funções privadas e não em membros também? Também não é privado? Ou o sublinhado dá um significado diferente à própria função?

Agora que você mencionou, sim, eu prefiro o sublinhado para os atributos também. Você pode ter algo como:

private _foo: string;

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

get foo() { return this._foo; }

Com setter e getters mais complexos, é claro.

sim, erro de digitação

Pessoalmente, não gosto de sublinhados ... mas como não existe nenhum privado ou público real no javascript, é muito útil ter uma maneira de diferenciá-los. Então eu os uso

ATUALIZAÇÃO: eu estava me referindo a ES5 ... com Typescript, não uso sublinhado

Você acha que haverá confusão se o sublinhado for omitido?

O TypeScript / JavaScript não tem verdadeiras variáveis ​​privadas e o uso de classes significa que temos ainda menos capacidade de ocultar variáveis ​​do que no JavaScript pré-classe. Temos apenas a convenção '_' para nos salvar.

O principal valor da convenção '_' é que grita " Não toque! ". Ao depurar o JavaScript, é tudo o que temos para prosseguir.

Quando as pessoas veem something.foo no depurador, elas não podem saber com certeza se foo é (a) público e não documentado ou (b) privado. Sem o aviso adequado, eles se sentem livres para fazer referência a ele em seu próprio código. Nesse momento, o desenvolvedor incorre em uma obrigação de suporte.

Quando os leitores virem _foo , eles devem saber que está fora dos limites . Se eles fizerem referência a _foo eles o farão _ por sua própria conta e risco_. Não deve haver rasgos quando o desenvolvedor o remove ou muda seu comportamento.

Em nossos documentos e exemplos, os membros privados devem começar com '_'. Onde negligenciamos a prefixação de um privado com '_', corrigimos isso rapidamente.

A suposição de Ward é que estaríamos depurando o javascript .... para alguns que podem parecer estranhos, mas vejo isso como um ótimo plano de backup se os mapas de origem não funcionarem tão bem ou se apenas quisermos um entendimento mais claro do que está acontecendo.

É também um ótimo indicador visual de como usá-lo.

Tudo o que Ward disse.

Também com o ng2 podemos ter uma referência como:

<my-dir #myDir>

e acessar os atributos internos. Se um deles tiver um sublinhado, é um sinal de "isso pode ser quebrado amanhã, não faça isso"

Concordo, não há maneira melhor de distingui-los. É uma velha escola para desenvolvedores. Não faz mal a nada, exceto a conveniência.

As edições do Angular 2 irão agora para o guia de estilo A2 no repo angular.io

Observe que o estilo de código angular atual sugestão de

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.

Portanto, este é o inverso do que é sugerido nesta edição.

Quando li esta edição pela primeira vez, pensei ter encontrado uma diferença, mas a regra atualizada / invertida ESTÁ de acordo com as diretrizes de codificação de texto datilografado (regra nº 6 para nomes).

Acho que o argumento TypeScript tooling pode ter influenciado John. Visto que ele é tão fluente em Gulp, ele pode ter decidido que não ter arquivos .map em funcionamento para depuração é apenas uma situação impraticável, que deve ser remediada diretamente, em vez de corrigi-lo em seu código enchendo-o de sublinhados: P.