¿Por qué no debería ponerle prefijo a mis campos?[cerrado]

Question

Nunca he sido un fanático de la notación húngara, siempre la he encontrado bastante inútil a menos que estés haciendo programación de muy bajo nivel, pero en cada proyecto de C++ en el que he trabajado se aplicó algún tipo de política de notación húngara, y con ello el uso de algunos prefijos 'no realmente húngaros' como m_ para campos, s_ para estática, g_ para globales, etc.

Pronto me di cuenta de lo inútil que era C# y gradualmente comencé a abandonar todos mis viejos hábitos...pero lo de 'm_'.Todavía uso el prefijo m_ en campos privados porque realmente lo encuentro muy útil para poder distinguir entre parámetros, locales y campos.

El convenciones de nomenclatura para la página de campos en MSDN dice que no debería, pero no dice por qué (la forma en que, p. ej.Las convenciones de Google tienden generalmente a racionalizar sus prescripciones).

¿Hay razones por las que no debería hacerlo o es sólo una cuestión de estilo?Si es lo último, ¿los prefijos generalmente se consideran un mal estilo y puedo esperar reacciones negativas de otras personas que trabajan en el código base?

Answer 1

Me gusta el prefijo de barra inferior para los campos de miembros. Principalmente me gusta porque de esa manera, todos mis campos de miembros se muestran alfabéticamente antes que mis métodos en la barra del asistente en la parte superior de la pantalla.

Answer 2

Cuándo deberías:

• Cuando las pautas de codificación de su proyecto dicen que debería

Cuando no deberías:

• Cuando las pautas de codificación de tu proyecto dicen que no deberías

Si aún no tiene pautas, puede elegir lo que usted o su equipo quieran y sentirse más cómodos. Personalmente, cuando codifico C ++, tiendo a usar m_ para los miembros, ayuda. Al codificar en otros idiomas, particularmente aquellos sin clases verdaderas (como Javascript, Lua) no lo hago.

En resumen, no creo que haya un " correcto " y un " incorrecto " manera.

Answer 3

La característica de propiedad implementada automáticamente en C # 3.0 crea menos necesidad de esta convención de una forma u otra. En lugar de escribir

string m_name;
public string Name { get { return m_name; } }

o

string _Name;
public string Name { get { return _Name; } }

(o cualquier otra convención), ahora puede escribir

public string Name { get; private set; }

Como ya no necesita la variable de almacén de respaldo explícito, ya no tiene que encontrar un nombre para ella; evitando así toda esta discusión.

Obviamente, este argumento no se aplica cuando realmente necesita un almacén de respaldo explícito como para realizar la validación.

Answer 4

Como algunos han aludido, las pautas de MS dicen:

  

No use un prefijo para los nombres de campo.   Por ejemplo, no use g_ o s_ para   distinguir estático versus no estático   campos.

Estoy de acuerdo con esto. los prefijos hacen que su código se vea feo y desperdicie espacio con caracteres intrascendentes. Dicho esto, a menudo es común usar campos para respaldar propiedades donde tanto el campo como la propiedad tendrían el mismo nombre (con el campo privado en mayúscula y la propiedad en mayúscula). En VB, esto no funciona, ya que VB no distingue entre mayúsculas y minúsculas. En este escenario, recomiendo el uso de un solo prefijo _. Ni mas ni menos. Simplemente se ve más limpio, en mi humilde opinión.

Answer 5

He experimentado con m_, s_, solo _ y sin prefijo. He decidido usar solo _ para todas las variables estáticas y de instancia. No me parece importante distinguir las variables estáticas de las variables de instancia. En teoría suena bien, en la práctica no crea un problema.

Un compañero de trabajo una vez hizo un argumento convincente para eliminar todos los prefijos, lo probamos en un proyecto y funcionó mejor de lo que esperaba. Lo llevé a mi próximo proyecto y me molestó que & "Interfiera &"; con Intellisense Cuando tienes la siguiente situación

int foo;
public int Foo
{
  get { return foo; }
}

Comenzar a escribir foo sugerirá tanto la variable de instancia como la propiedad. Prefijar la variable con un guión bajo elimina la sugerencia doble molesta, así que volví a usar solo _.

Answer 6

Intento seguir las directrices de la biblioteca de MSDN .NET . Incluyen una sección directrices de nombres .

Obviamente, estos son secundarios a las pautas de su proyecto.

Answer 7

Prefiero marcar los campos de respaldo de propiedades (aunque como ya se mencionó .NET 3.0+ reduce la necesidad gracias a las Propiedades automáticas) con guiones bajos pero no con " m " ;. Por un lado, los coloca en la parte superior de la lista InteliSense cuando vengo a usarlos.

Admito que necesito repasar las pautas sobre MSDN, las cosas pueden cambiar tan rápido en estos días.

Answer 8

Con herramientas como resharper realmente no hay razón para prefijos. Además, si escribe métodos cortos, debería poder saber muy rápidamente de dónde proviene la var. Finalmente, supongo que realmente no vería la necesidad de diferenciar entre una estática o no, porque de nuevo el compartidor se pondrá en línea roja si intentas hacer algo que no puedes. Incluso sin resharper probablemente seas guardado por el compilador.

Answer 9

Siempre prefijo las variables miembro con m_ y las variables estáticas con s_ por las mismas razones que usted dice. Algunas personas prefieren las variables miembro con un guión bajo, pero siempre me ha parecido un poco extraño (pero eso es solo una preferencia personal).

La mayoría de las personas con las que trabajo usan el prefijo m_ / s_. Realmente no creo que importe demasiado lo que uses, siempre y cuando seas consistente.

Answer 10

Nunca los uso. Fomenta la codificación descuidada. Las pautas de codificación de MSDN, ahí es donde está.

Answer 11

Aquí hay algunas razones para usar _ (y no m_).

(1) Muchos chicos de BCL lo hacen a pesar de la guía de nombres de MS. (Echa un vistazo a su blog .) Esos tipos escriben el marco, por lo que tienen algunos buenos hábitos Vale la pena copiar. Algunos de los códigos de ejemplo más útiles en MSDN están escritos por ellos y, por lo tanto, utilizan la convención de subrayado. Es un estándar industrial de facto.

(2) Un solo guión bajo es una forma notable pero discreta de desambiguar el método y las variables a nivel de clase simplemente leyendo la fuente. Ayuda a las personas a comprender el código nuevo (o antiguo) at-a-glance al leerlo. Sí, puede pasar el mouse para ver esto en un IDE, pero no debemos obligarnos a hacerlo. Es posible que desee leerlo en un editor de texto, o me atrevo a decirlo en papel.

(3) Algunos dicen que no necesita ningún prefijo ya que los métodos serán cortos, y más tarde, si es necesario, puede cambiar el campo a una propiedad implementada automáticamente. Pero en el mundo real, los métodos son tan largos como sea necesario y existen diferencias importantes entre los campos y las propiedades (por ejemplo, serialización e inicialización).

Nota al pie: El " m " for member in m_ es redundante en nuestro uso aquí, pero era minúscula porque una de las ideas en muchas de estas convenciones de nomenclatura antiguas era que los nombres de tipo comenzaban con mayúscula y los nombres de instancia comenzaban con minúscula. Eso no se aplica en .NET, por lo que es doblemente redundante. También la notación húngara a veces era útil con los compiladores de C antiguos (por ejemplo, la conversión de enteros o punteros y la aritmética), pero incluso en C ++ su utilidad se redujo cuando se trata de clases.

Answer 12

Hay una diferencia importante entre C ++ y C #: soporte de herramientas. Cuando siga las pautas establecidas (o variaciones comunes), obtendrá un nivel profundo de soporte de herramientas que C ++ nunca tuvo. Seguir los estándares permite que las herramientas realicen operaciones de refactorización / cambio de nombre más profundas de lo que de otra manera sería capaz. Resharper hace esto. Así que cumpla con uno de los estándares establecidos.

Answer 13

Como menciona @John Kraft, no existe una respuesta "correcta".MattJ es el más cercano: siempre debes seguir las pautas de estilo de tu empresa.Cuando en Roma y todo eso.

En cuanto a mi opinión personal, como aquí se pide, voto que lo dejes caer. m_ enteramente.

Creo que el mejor estilo es aquel en el que todos los miembros están PascalCased, independientemente de la visibilidad (eso significa incluso private miembros), y todos los argumentos son camelCased.No rompo este estilo.

Puedo entender el deseo de anteponer el campo de la tienda de respaldo de propiedad;al fin y al cabo hay que diferenciar entre el campo y la propiedad, ¿no?Estoy de acuerdo, debes hacerlo.Pero use una corrección posterior.

En lugar de m_MyProperty (o incluso _MyProperty, que he visto e incluso promocionado alguna vez), use MyPropertyValue.Es más fácil de leer y comprender y, lo que es más importante, se acerca al nombre de su propiedad original en Intellisense.

En última instancia, esa es la razón por la que prefiero un sufijo.Si quiero acceder MyPropertyValue usando intellisense usted (normalmente) escribe "My <down-arrow> <tab>", ya que para entonces estás lo suficientemente cerca como para que solo MyProperty y MyPropertyValue están en la lista.Si quieres acceder m_MyProperty usando intellisense, tendrás que escribir "m_My <tab>".

En mi opinión, se trata de economía de pulsaciones de teclas.

Answer 14

Nunca hago esto y la razón es que [intento] mantener mis métodos cortos. Si puedo ver todo el método en la pantalla, puedo ver los parámetros, puedo ver a los locales y así puedo decir qué es propiedad de la clase y qué es un parámetro o un local.

Normalmente nombro mis parámetros y locales usando una notación particular, pero no siempre. No soy nada si no inconsistente. Confío en el hecho de que mis métodos son cortos e intento evitar que hagan X, Y y Z cuando solo deberían hacer X.

De todos modos, esos son mis dos centavos.

Answer 15

A menos que esté atascado con vi o Emacs para editar el código, mi IDE se encarga de la visualización diferencial de miembros para mí, por lo que rara vez utilizo alguna convención especial. Eso también se aplica a las interfaces de prefijo con I o clases con C.

Alguien, por favor, explique el estilo .NET del prefijo I en las interfaces. :)

Answer 16

a lo que estoy acostumbrado es que las propiedades privadas tienen un pequeño guión bajo f.ex " string _name " ;. el público obtuvo " Nombre " ;. y las variables de entrada en los métodos obtuvieron una letra minúscula " void MyMethod (nombre de cadena) " ;.

si tienes constante estática a menudo se escribe con letras grandes. static const MYCONST = "hmpf".

Answer 17

Nunca uso verrugas húngaras cuando tengo la opción. Es un tipeo adicional y no transmite ninguna información significativa. Cualquier IDE bueno (y defino & "; Bueno &"; Basado en la presencia de esta característica, entre otras) le permitirá tener un resaltado de sintaxis diferente para miembros estáticos, miembros de instancia, funciones de miembro, tipos, etc. No hay ninguna razón para saturar su código con información que puede proporcionar el IDE. Esto es un corolario para no saturar su código con código antiguo comentado porque su sistema de versiones debería ser responsable de esas cosas.

Answer 18

La mejor manera es acordar un estándar con sus colegas y cumplirlo. No tiene que ser absolutamente el método que funcione mejor para todos, simplemente acordar un método es más importante que el método en el que realmente está de acuerdo.

Lo que elegimos para nuestro código estándar es usar _ como prefijo para las variables miembro. Una de las razones fue que facilita encontrar las variables locales en el intellisense.

Antes de acordar ese estándar, usé otro. No usé ningún prefijo en absoluto, y escribí this.memberVariable en el código para mostrar que estaba usando una variable miembro.

Con la propiedad abreviada en C # 3, encuentro que utilizo muchas menos variables de miembro explícitas.

Answer 19

Lo más parecido a las pautas oficiales es StyleCop , una herramienta de Microsoft que puede analizar automáticamente sus archivos de origen y detectan violaciones del estilo de codificación recomendado, y se pueden ejecutar desde Visual Studio y / o compilaciones automatizadas como MSBuild.

Lo usamos en nuestros proyectos y ayuda a hacer que el estilo y el diseño del código sean más consistentes entre los desarrolladores, aunque tenga en cuenta que a bastante le cuesta un poco acostumbrarse.

Para responder a su pregunta, no permite ninguna notación húngara, ni prefijos como m_ (de hecho, no permite el uso de guiones bajos en absoluto).

Answer 20

Ya no uso ese estilo. Fue desarrollado para ayudarlo a ver rápidamente cómo se usaban las variables. Los entornos de desarrollo más nuevos le permiten ver esa información al pasar el mouse sobre la variable. La necesidad ha desaparecido si usas esas herramientas más nuevas.

Answer 21

También podría obtenerse alguna idea de los Estándares de codificación C ++ ( Sutter, Herb y Alexandrescum Andrei , 2004). El artículo # 0 se titula & Quot; No se preocupe por las cosas pequeñas. (O: sepa qué no estandarizar). & Quot ;.

Tocan un poco esta pregunta específica diciendo " Si no puede decidir sobre su propia convención de nomenclatura, intente ... variables de miembros privados likeThis_ ... < !> quot; (Recuerde que el uso del guión bajo está sujeto a reglas muy específicas en C ++).

Sin embargo, antes de llegar allí, enfatizan un cierto nivel de consistencia " ... lo importante no es establecer una regla sino ser coherente con el estilo que ya está en uso dentro del archivo ... "

Answer 22

El beneficio de esa notación en C / C ++ era facilitar la visualización del tipo de símbolo sin tener que buscar la declaración. Estos estilos aparecieron antes de la llegada de Intellisense y & Quot; Ir a Definición & Quot; - a menudo teníamos que ir en busca de la declaración de quién sabe cuántos archivos de encabezado. En un proyecto grande, esto podría ser una molestia significativa que era lo suficientemente mala cuando se miraba el código fuente de C, pero aún peor cuando se hacía análisis forense con ensamblaje mixto + código fuente y una pila de llamadas sin procesar.

Cuando nos enfrentamos a estas realidades, el uso de m_ y todas las demás reglas húngaras comienza a tener sentido incluso con la sobrecarga de mantenimiento debido a cuánto tiempo ahorraría solo al buscar el tipo de un símbolo cuando se mira un código desconocido. Ahora, por supuesto, tenemos Intellisense y & Quot; Ir a Definición & Quot ;, por lo que la motivación principal para ahorrar tiempo de esa convención de nombres ya no está allí. Creo que ya no tiene mucho sentido hacerlo, y generalmente trato de seguir las pautas de la biblioteca .NET solo para ser coherente y posiblemente obtener un poco más de soporte de herramientas.

Answer 23

Estoy seguro de que seré criticado por esto, pero que así sea.

Se llama las pautas de la biblioteca .NET de Microsoft, pero en realidad es Vistas de Brad Abrams ( documento aquí ) - hay otras opiniones con razones válidas.

Las personas tienden a ir con la opinión de la mayoría en lugar de tener buenas razones sólidas para un estilo específico.

El punto importante es evaluar por qué se usa un estilo específico y por qué se prefiere sobre otro estilo; en otras palabras, tener una razón para elegir un estilo, no solo porque todo el mundo dice que es lo que hay que hacer, piensa por ti mismo.

La razón básica para no usar el estilo antiguo húngaro fue el uso de abreviaturas que eran diferentes para cada equipo y difíciles de aprender; esto se resuelve fácilmente al no abreviar.

A medida que las herramientas de desarrollo disponibles cambian, el estilo debe cambiar a lo que tiene más sentido, pero tiene una razón sólida para cada elemento de estilo.

A continuación están mis pautas de estilo con mis razones: siempre estoy buscando formas de mejorar mi estilo para crear un código más confiable y más fácil de mantener.

Convención de nomenclatura variable

Todos tenemos nuestra opinión sobre las convenciones de nomenclatura variable. Hay muchos estilos diferentes que ayudarán a producir un código de calidad fácil de mantener: cualquier estilo que admita la información esencial básica sobre una variable está bien. El criterio para una convención de nomenclatura específica debería ser que ayuda a producir código que sea confiable y fácil de mantener. Los criterios que no deben usarse son: Es feo Microsoft (es decir, Brad Abrams) dice que no use ese estilo: Microsoft no siempre produce el código más confiable, solo mire los errores en Expression Blend. Al leer el código, es muy importante que el nombre de una variable transmita instantáneamente tres hechos esenciales sobre la variable: es & # 8217; s alcance  es & # 8217; s tipo una clara comprensión de para qué se utiliza Alcance: Microsoft recomienda confiar totalmente en IntelliSense. IntelliSense es asombroso; sin embargo, uno simplemente no pasa el mouse sobre cada variable para ver su alcance y tipo. Asumir que una variable está dentro de un alcance que no lo es puede causar errores significativos. Por ejemplo, si una variable de referencia se pasa como parámetro y se modifica en el ámbito local, ese cambio permanecerá después de que el método regrese, lo que puede no ser deseado. Si un campo o una variable estática se modifica en el ámbito local, pero se piensa que es una variable local, podría producirse un comportamiento inesperado. Por lo tanto, es extremadamente importante poder mirar una variable (no pasar el mouse) y saber instantáneamente su alcance.

Se sugiere el siguiente estilo para indicar el alcance; sin embargo, cualquier estilo está perfectamente bien siempre que indique clara y consistentemente el alcance de la variable: variable de campo m_ p_ parámetro pasado a un método s_ variable estática         variable local Tipo: pueden producirse errores graves si uno cree que están trabajando con un tipo específico cuando realmente están trabajando con un tipo diferente; nuevamente, simplemente no pasamos el mouse por encima de las variables para determinar su tipo, simplemente asumimos que sabemos cuál es su tipo es y así es como se crean los errores.

Abreviaturas: las abreviaturas son malas porque pueden significar diferentes cosas para diferentes desarrolladores. Un desarrollador puede pensar en minúsculas & Quot; s & Quot; significa cadena mientras que otro puede pensar que significa entero con signo. Las abreviaturas son un signo de codificación diferida: tómese un poco más de tiempo y escriba el nombre completo para dejar en claro al desarrollador que debe mantener el código. Por ejemplo, la diferencia entre & Quot; str & Quot; y " string " son solo tres caracteresters: no hace falta mucho más esfuerzo para hacer que el código sea fácil de mantener.

Las abreviaturas comunes y claras para los tipos de datos integrados solo son aceptables, pero deben estandarizarse dentro del equipo.

Código de autodocumentación: agregar una descripción clara al nombre de una variable hace que sea muy fácil para otro desarrollador leer y comprender el código; haga que el nombre sea tan comprensible que el gerente del equipo pueda leer y comprender el código sin ser un desarrollador.

Orden de partes de nombre de variable: El orden recomendado es descripción de tipo de alcance porque: IntelliSense agrupará todos los ámbitos similares y dentro de cada ámbito IntelliSense agrupará todos los tipos similares, lo que facilita las búsquedas; intente encontrar una variable de la otra manera Hace que sea muy fácil ver y comprender el alcance y ver y comprender el tipo Es un estilo bastante común y fácil de entender. Pasará FxCop

Ejemplos: Aquí hay algunos ejemplos: m_stringCustomerName p_stringCustomerDatabaseConnectionString intNumberOfCustomerRecords o iNumberOfCustomerRecords o integerNumberOfCustomerRecords Estas simples reglas mejorarán significativamente la confiabilidad y la facilidad de mantenimiento del código.

Estructura de control declaraciones de línea única Todas las estructuras de control (if, while, for, etc.) siempre deben estar envueltas con llaves porque es muy fácil agregar una nueva instrucción sin darse cuenta de que una instrucción dada pertenece a una estructura de control que romperá la lógica del código sin generar errores de tiempo de compilación.

Ajuste de excepción de método Todos los métodos deben estar envueltos con un try-catch externo que atrape, proporcione un lugar para recuperarse, identificar, ubicar, registrar y tomar la decisión de lanzar o no. Es la excepción inesperada que hace que nuestras aplicaciones se bloqueen: al envolver cada método para atrapar todas las excepciones no controladas, garantizamos la identificación y el registro de todas las excepciones y evitamos que nuestra aplicación se bloquee. Se necesita un poco más de trabajo, pero los resultados bien valen la pena.

Sangría La sangría no es un problema importante; sin embargo, se sugieren cuatro espacios y no usar pestañas. Si se imprime el código, la primera pestaña de la impresora generalmente tiene 8 espacios predeterminados. Los diferentes desarrolladores tienden a usar diferentes tamaños de pestaña. El código de Microsoft generalmente tiene 4 espacios sangrados, por lo que si uno usa cualquier código de Microsoft y usa otros 4 espacios, entonces el código deberá formatearse nuevamente. Cuatro espacios lo hacen fácil y consistente.

Answer 24

Si no está codificando bajo una directriz particular, debe seguir usando su notación m_ real y cambiarla si las pautas de codificación del proyecto lo dicen.

Answer 25

Sea funcional.

• No use variables globales.
• No use variables estáticas.
• No use variables miembro.

Si realmente tiene que hacerlo, pero solo si realmente tiene que hacerlo, use una y solo una variable para acceder a su aplicación / entorno.