Convención de nomenclatura para campos privados
Primero, sé que esta pregunta se ha hecho varias veces antes y que al final, es principalmente una cuestión de preferencia personal, pero leyendo todos los hilos sobre el tema, algunas cosas no están claras para mí.
Básicamente, algo con lo que la mayoría de la gente está de acuerdo al menos es que los miembros públicos deben ser PascalCased mientras que los miembros privados deben ser lowerCamelCased.
La cuestión que suele suscitar debate es si se anteponen o no los miembros privados con un subrayado, o cualquier otra cosa. El prefijo viola varias reglas de StyleCop (que obviamente se pueden desactivar)
La razón para no poner prefijos es que debe usar esto. prefijo en su lugar.
El problema que tengo es que no entiendo cómo está haciendo una diferencia? Quiero decir, no es como si no pudieras usar esto en un miembro público de todos modos dentro de una clase.
Imaginemos un Cliente de clase, con este aspecto:
class Customer
{
private int age;
public int Age
{
get { return this.age; }
set { this.age = value; }
}
}
(Obviamente, en un caso tan simple, podría usar un autoproperty, pero eso es solo un ejemplo).
Si agrego una segunda propiedad dentro de esta clase, nada me impediría referirme a ella usando esto.Edad (la propiedad pública) en lugar de esto.edad (el campo privado). A veces, incluso podría ser wishable, si se aplicara alguna validación o formato en el nivel getter.
Además, si algunas otras propiedades de mi clase necesitan modificar la Edad del cliente, tendría sentido usar la propiedad en lugar del campo de respaldo directamente como el creador también podría implementar algunas validaciones de reglas de negocio, ¿verdad?
En otras palabras, realmente no veo cómo la palabra clave this evita la confusión entre los miembros de respaldo privados y las propiedades públicas, ya que esto se puede usar en ambos e IntelliSense muestra ambos?
Gracias.
4 answers
Tienes toda la razón. No lo hace.
Usar this es una forma de asegurarse de que está utilizando el miembro de la clase, en caso de conflictos de nombres (digamos un nombre de parámetro que es idéntico al nombre de un campo).
Para mí, pascal casing miembros públicos y camel casing miembros privados siempre ha sido suficiente de una convención para funcionar bien.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-12-27 16:37:12
Prefiero la convención " _ " líder para los campos privados, a pesar de que no sigue las convenciones de MS:
-
Elimina conflictos con nombres de parámetros de camello-no es necesario usar"this"
Es un indicador visual de que el estado persistente interno del objeto se está leyendo o, lo que es más importante, se está escribiendo. Es una bandera que dice "esto tiene efectos secundarios fuera del método particular que estoy viendo" , que es muy es importante saber cuando se mira código desconocido.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-12 21:48:30
Usar this.age podría ayudar a distinguir entre el almacén de respaldo de su propiedad Age y un parámetro age para un método en su objeto:
public bool CheckIfOlderThan(int age)
{
// in here, just using "age" isn't clear - is it the method parameter?
// The internal field?? Using this.age make that clear!
return (this.age >= age);
}
Por supuesto, en este caso, también podría darle a su parámetro un nombre menos confuso para evitar cualquier conflicto....
Pero en la definición real de la propiedad - leer y almacenar su valor en el almacén de respaldo - agregar el this. realmente no agrega nada. Algunas personas que conozco prefieren usar el prefijo this. todo el tiempo - no justo cuando es necesario - preferencia personal, realmente...
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-12-27 16:38:10
Prefijar campos privados con subrayado es básicamente lo mismo que usar "this.". Sin embargo, underscore es más rápido de usar, más corto y más elegante para mí (creo que esto proviene de Java).
Tener los mismos nombres para los parámetros de función y los campos privados me parece un poco complicado. No solo una vez me he olvidado de usar "esto" que resultó en NullPointerException desagradable (sí, hice java algún día... :) ).
Por lo que sé, no viola ninguna regla de FxCop, ya que no es un notación húngara.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-01-02 11:05:49