Convenciones de nomenclatura variable? [cerrado]

Acabo de comenzar a usar ReSharper (para C #) y me gusta su buscador de olores de código, me muestra algunas cosas sobre mi escritura que pretendía arreglar hace mucho tiempo (principalmente convenciones de nombres variables).

Me hizo reconsiderar algunas de mis convenciones de nomenclatura para métodos y variables de instancia. ReSharper sugiere que la variable de instancia sea minúscula y comience con un guión bajo. Durante un tiempo tuve la intención de reducir todas las variables locales a mayúsculas y minúsculas, pero ¿es necesario el guión bajo? ¿Te resulta cómodo? No me gusta esta convención pero tampoco la he probado todavía, ¿cuál es su opinión al respecto?

La segunda cosa que me impulsó a reevaluar es mis convenciones de nomenclatura para controladores de eventos GUI. Usualmente uso el estándar VS de ControlName_Action y mis controles usualmente usan notación húngara (como sufijo, para ayudar a aclarar en el código qué es visible para el usuario y qué no cuando se trata con una variable con un nombre similar), así que termino con OK_btn_Click ( ), ¿cuál es su opinión al respecto? ¿Debería sucumbir a la convención ReSharper o hay otras opciones igualmente válidas?

Puede modificar ReSharper para utilizar el esquema de convención de nomenclatura que utilice. Es bastante flexible, e incluye la personalización de controladores de eventos, campos, propiedades, métodos con varios niveles de accesibilidad, etc.

No permita que la herramienta defina sus estándares, úsela para hacer cumplir los suyos.

Actualización: Dicho esto, en el trabajo usamos principalmente mayúsculas y minúsculas para la mayoría de las cosas privadas: variables, campos y argumentos. Mayúscula en camello para nombres de métodos, constantes y propiedades. Los controladores de eventos se nombran en función de la acción que representan, en lugar de algo específico para el control, por ejemplo, HandleCustomerContinue en lugar de HandleContinueButtonClick. Probé el esquema predeterminado de ReSharper por un tiempo y en realidad no me importa, realmente no estoy preocupado de ninguna manera.

Con respecto a

pero es necesario el guión bajo? ¿Te resulta cómodo?

Una cosa que me gusta mucho de usar el guión bajo es que reduce drásticamente el uso de "esto".

Considerar:

public void Invoke(int size) {
    _size = size;
}

sin el guión bajo, tendrías que escribir:

public void Invoke(int size) {
    this.size = size;
}

que potencialmente introduce el sutil error de:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

Además, la finalización del código es más limpia porque al vincular el guión bajo se obtiene una lista de solo los campos privados, mientras que con "esto" se obtiene una lista de todo.

Con respecto a

usualmente uso notación húngara

Las Directrices de diseño del marco: convenciones, Idoms y patrones para bibliotecas .NET reutilizables dicen:

NO use la notación húngara

Dejando poco espacio para la ambigüedad :)

La consistencia es realmente la clave. Eso y claridad, es decir, no seas críptico ni intentes guardar la escritura abreviando todo. Intellisense es su protector de escritura, no nombres crípticos (¡sino cortos!).

En C #, el inicio protegido o el nombre público con guión bajo va en contra de la especificación de lenguaje común. Es correcto solo en caso de miembros privados.

De MSDN:

Para interactuar completamente con otros objetos, independientemente del idioma en el que se implementaron, los objetos deben exponer a las personas que llaman solo aquellas características que son comunes a todos los idiomas con los que deben interactuar. Por esta razón, se ha definido la Especificación del lenguaje común (CLS), que es un conjunto de características básicas del lenguaje que necesitan muchas aplicaciones.

Ver: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Aquí puede leer la advertencia sobre el guión bajo:

Los nombres de elementos que comienzan con un guión bajo (_) no forman parte de la Especificación del lenguaje común (CLS), por lo que el código compatible con CLS no puede usar un componente que defina dichos nombres. Sin embargo, un guión bajo en cualquier otra posición en un nombre de elemento es compatible con CLS.

Ver: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Los miembros protegidos son un problema porque puede heredar de una clase escrita en otro idioma.

Pero tal vez no sea un problema en su caso si no necesita un código compatible con CLS.

Me gustan los guiones bajos. Usted sabe a primera vista que la variable es un miembro de la clase y privada.

Seguro que el IDE puede decirte eso cuando pasas el mouse sobre él, pero la "primera vista" no puede ser vencida. Usted sabe qué es una variable local, y cuál es una variable miembro solo con sus ojos. No se requiere desplazamiento ni desplazamiento del mouse.

Puede usar la palabra clave "this" pero _ es más corta para una mejor escalabilidad horizontal. Generalmente se desean nombres descriptivos, pero cuando algo es una convención establecida, es mejor tener 1 carácter. por ejemplo, usando la letra i como índice al recorrer una matriz. Dado que es una convención establecida que i es un índice, obtienes el beneficio de la escalabilidad sin el inconveniente de preguntarte qué significa "i".

En general, estoy de acuerdo con lo que dicen otros, sin embargo, cuando se trata de herramientas y cadenas de herramientas, soy flojo y me gusta una vida fácil. Encuentro que la vida es a menudo más fácil simplemente hacerlo de la manera que sugieren. Las razones son

• Es más fácil de instalar (solo usa los valores predeterminados, incluso puedo presionar Enter 20 veces y ponerlo en marcha)
• Los errores generalmente se han solucionado con la configuración predeterminada, a menudo es la configuración esotérica que configuré la que expone un defecto por primera vez
• El vendedor de la cadena de herramientas probablemente sabe más sobre esto que yo, por lo tanto, lo hicieron así por una razón. ¿Quién soy yo para decidir que los expertos están equivocados? (Los considero expertos porque compré su herramienta)
• Nunca tendrá que defender la elección de los vendedores por parte de un Gerente - "Es lo que recomiendan"
• El nuevo chico no te molestará con "por qué" y "Es mejor así" - Cuando cada respuesta es "porque decidieron ..."

Entonces, mi opinión sería si puedes encontrar una razón válida para reconfigurar las herramientas en las que acabas de gastar una fortuna, hazlo por todos los medios. Si no puede justificar el cambio, no lo haga.

Tenga en cuenta que cada cambio tiene un costo continuo (real y oculto) para mantener. Cuanto menos hay, menor es el costo. Por ejemplo, ese chico nuevo que mencioné, sin cambios significa que puede leer su manual. Reconfigurar: debe escribir el apéndice, guardarlo con otras cosas, retirarlo y hacer que lo lea después de leer su manual. Tal vez no sea un problema para una tienda de 2 hombres, pero ¿qué pasa con una tienda de 100 hombres?

Las dos reglas sobre las que está preguntando, subrayan al comienzo de los nombres de campo privados, y los nombres de métodos generalmente se consideran la norma en los círculos de desarrollo de C #. Al adaptarse a esas convenciones, su código será inmediatamente más comprensible para otros desarrolladores porque ese es el estado de ánimo en el que están acostumbrados a operar.

El sufijo de Label, RadioButton, etc. para sus controles generalmente también se considera la norma. Con frecuencia existirán múltiples controles para un solo concepto (por ejemplo, una etiqueta y un cuadro de texto), y este sufijo es bastante útil. Cierto notación húngara se abandonó hace mucho tiempo porque se ha convertido en algo que no expresa su intención original, que era el contexto sobre la variable, no qué tipo, tamaño, etc.

En mi caso, el uso de camelcase y guiones bajos ayuda con los nombres de variables descriptivas (lectura: larga) y la finalización del código. No estoy muy seguro de cómo funciona el autocompletado de Visual Studio, pero en QtCreator y, en menor medida, Eclipse, uno puede escribir, por ejemplo

sDI

y expandirlo a

someDescriptiveIdentifier

Guarda un poco de escritura en caso de que tenga nombres como

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

que tiendo a producir cuando estoy en "modo de denominación descriptiva".

Usando guiones bajos puedo determinar qué nombre quiero autocompletar

someDescriptiveIdentifier

o

_someDescriptiveClassMember

Espero que mi explicación sea lo suficientemente clara :)