Angular-styleguide: convención sobre miembros públicos / privados

Estoy totalmente de acuerdo con eso. Lo siento, me perdí esa parte.

Frio.

Y creo que su problema tiene cierta perspectiva que es importante agregar a la guía, así que lo volveré a abrir. :)

Me gustaría agregar la parte sobre el nombre de estos a la guía. Si preguntaste, alguien más también lo hará.

¿Cuál es el punto de usar un guión bajo en los nombres de funciones privadas y no en los miembros también? ¿No es también privado? ¿O el subrayado le da un significado diferente a la función en sí?

Ahora que lo mencionas, sí, prefiero el subrayado para los atributos también. Puedes tener algo como:

private _foo: string;

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

get foo() { return this._foo; }

Con setter y getters más complejos, por supuesto.

si, error tipográfico

No me gustan los guiones bajos personalmente ... pero como no hay ningún público ni privado real en javascript, es muy útil tener una forma de diferenciarlos. Entonces los uso

ACTUALIZACIÓN: me estaba refiriendo a ES5 ... con Typecript no uso el subrayado

¿Crees que habrá confusión si se omite el subrayado?

TypeScript / JavaScript no tiene verdaderas variables privadas y el uso de clases significa que tenemos incluso menos capacidad para ocultar variables que en JavaScript anterior a la clase. Solo tenemos la convención '_' para salvarnos.

El valor principal de la convención '_' es que grita " ¡No tocar! ". Al depurar JavaScript, es todo lo que tenemos que hacer.

Cuando las personas ven something.foo en el depurador, no pueden saber con certeza si ese foo es (a) público e indocumentado o (b) privado. Sin previo aviso, pueden hacer referencia a él en su propio código. En ese momento, el desarrollador incurre en una obligación de soporte.

Cuando los lectores ven _foo , deben saber que está fuera de los límites . Si hacen referencia a _foo lo hacen _ bajo su propio riesgo_. No debe haber lágrimas cuando el revelador lo quita o cambia su comportamiento.

En nuestros documentos y muestras, los miembros privados deben comenzar con '_'. Cuando nos hemos olvidado de prefijar un privado con '_', lo corregimos rápidamente.

La suposición de Ward es que estaríamos depurando el javascript ... para algunos que puede parecer extraño, pero lo veo como un gran plan de respaldo si los mapas de origen no funcionan tan bien o si solo queremos una comprensión más clara de lo que está sucediendo.

También es un gran indicador visual de cómo usarlo.

Todo lo que dijo Ward.

También con ng2 podemos tener una referencia como:

<my-dir #myDir>

y acceder a los atributos del interior. Si uno de ellos tiene un guión bajo, es una señal de "esto podría romperse mañana, no lo hagas".

De acuerdo, no hay mejor forma de distinguirlos. Es una vieja escuela para desarrolladores. No hace daño a nada excepto a la conveniencia.

Los problemas de Angular 2 ahora irán a la guía de estilo A2 en el repositorio de angular.io

Tenga en cuenta que el estilo de código angular actual @johnpapa aquí y ahora aconseja NO usar un guión bajo para las variables privadas:

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.

Entonces esto es lo contrario de lo que se sugiere en este número.

Cuando leí este número por primera vez, pensé que había encontrado una diferencia, pero la regla actualizada / invertida ESTÁ en línea con las pautas de codificación de mecanografiado (regla n ° 6 para los nombres).

Creo que el argumento TypeScript tooling podría haber influido en John. Al ver que domina Gulp con tanta fluidez, podría haber decidido que no tener archivos .map que funcionen para la depuración es solo una situación inviable, que debería remediarse directamente, en lugar de corregirlo en su código llenándolo de guiones bajos: P.