Angular-styleguide: convention autour des membres publics / privés

Je suis entièrement d'accord avec cela. Je suis désolé, j'ai raté cette partie.

Cool.

Et je pense que votre problème a une perspective qu'il est important d'ajouter au guide, je vais donc le rouvrir. :)

J'aimerais ajouter la partie sur les noms de ceux-ci au guide. Si vous avez demandé, alors quelqu'un d'autre le fera aussi.

Quel est l'intérêt d'utiliser le trait de soulignement dans les noms de fonctions privées et non dans les membres également ? N'est-ce pas aussi privé ? Ou, le soulignement donne-t-il un sens différent à la fonction elle-même ?

Maintenant que vous le mentionnez, oui, je préfère également le soulignement pour les attributs. Vous pouvez avoir quelque chose comme :

private _foo: string;

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

get foo() { return this._foo; }

Avec des setter et getters plus complexes bien sûr.

oui, faute de frappe

Personnellement, je n'aime pas les traits de soulignement ... mais comme il n'y a pas de réel privé ni public en javascript, il est très utile d'avoir un moyen de les différencier. donc je les utilise

MISE À JOUR: je faisais référence à ES5 ... avec Typescript, je n'utilise pas de trait de soulignement

Pensez-vous qu'il y aura confusion si le trait de soulignement est omis ?

TypeScript/JavaScript n'a pas de vraies variables privées et l'utilisation de classes signifie que nous avons encore moins de possibilité de masquer des variables que dans JavaScript pré-classe. Nous n'avons que la convention '_' pour nous sauver.

La valeur principale de la convention '_' est qu'elle crie " Ne touchez pas ! ". Lors du débogage du JavaScript, c'est tout ce que nous avons à faire.

Lorsque les gens voient something.foo dans le débogueur, ils ne peuvent pas savoir avec certitude si ce foo est (a) public et non documenté ou (b) privé. Sans préavis suffisant, ils se sentent libres de le référencer dans leur propre code. A ce moment-là, le développeur encourt une obligation de prise en charge.

Lorsque les lecteurs voient _foo , ils doivent savoir que c'est interdit . S'ils font référence à _foo ils le font _à leurs risques et périls_. Il ne doit pas y avoir de larmes lorsque le développeur le retire ou modifie son comportement.

Dans nos documents et exemples, les membres privés doivent commencer par '_'. Là où nous avons négligé de préfixer un privé avec '_', nous corrigeons cela rapidement.

L'hypothèse de Ward est que nous déboguerions le javascript... pour certains, cela peut sembler étrange, mais je le considère comme un excellent plan de sauvegarde si les sourcesmaps ne fonctionnent pas si rapidement ou si nous voulons simplement une meilleure compréhension de ce qui se passe.

C'est aussi un excellent indicateur visuel de la façon de l'utiliser.

Tout ce que Ward a dit.

Aussi avec ng2 nous pouvons avoir une référence comme :

<my-dir #myDir>

et accéder aux attributs à l'intérieur. Si l'un d'entre eux a un trait de soulignement, c'est le signal de "cela pourrait être cassé demain, ne le faites pas"

D'accord, pas de meilleure façon de les distinguer. C'est une vieille école pour les développeurs. Cela ne nuit à rien, sauf à la commodité.

Les problèmes d'Angular 2 iront désormais au guide de style A2 dans le référentiel angular.io

Veuillez noter que le style de code angulaire actuel (règle 03-04) a été modifié par rapport à la suggestion 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.

C'est donc l'inverse de ce qui est suggéré dans ce numéro.

Lorsque j'ai lu ce numéro pour la première fois, je pensais avoir trouvé une différence, mais la règle mise à jour/inversée EST conforme aux directives de codage dactylographiées (règle n° 6 pour les noms).

Je pense que l'argument TypeScript tooling pu influencer John. Étant donné qu'il maîtrise si bien Gulp, il a peut-être décidé que le fait de ne pas avoir de fichiers .map fonctionnels pour le débogage était simplement une situation impraticable, à laquelle il faudrait remédier directement, au lieu de la corriger dans votre code en le jonchant de traits de soulignement :P.