¿Carcasa Pascal o carcasa Camel para código C#?

Un enlace a las directrices oficiales de diseño podría ayudar. Específicamente, lea la sección sobre Estilos de mayúsculas.

En el gran esquema de las cosas, Pascal vs Camel no importa mucho y no es probable que convenza a nadie para volver sobre una base de código existente solo para cambiar el caso de los nombres. Lo que es realmente importante es que quieras ser consistente dentro de una base de código dada.

Estoy feliz mientras no estés usando húngaro.

Debería echar un vistazo a la nueva herramienta de Microsoft, StyleCop para comprobar el código fuente de C#. También esté atento a FxCop para comprobar ensamblados.Net compilados. FxCop se centra más en los detalles de lo que hace el código, no en el diseño, pero tiene algunas reglas de nomenclatura relacionadas con nombres visibles públicamente.

StyleCop define un estándar de codificación, que ahora está siendo promovido por Microsoft como un estándar de la industria. Comprueba el código fuente de C# contra el estándar. StyleCop se adhiere a tu estilo PascalCase.

Conseguir que las personas accedan a StyleCop (o a cualquier otro estándar) puede ser difícil, es un obstáculo y StyleCop es bastante exhaustivo. Pero el código debe ser un estándar uniforme, y un estándar personal es mejor que ninguno, el estándar de la empresa es mejor que uno personal, y un estándar de la industria es lo mejor de todo.

Es mucho más fácil convencer a la gente cuando se inicia un proyecto - se está formando un equipo y no hay código existente para convertir. Y tú puede poner herramientas (FxCop, StyleCop) en su lugar para romper la compilación si el código no cumple con los estándares.

Debe usar el estándar para el lenguaje y el marco: el código SQL debe usar estándares SQL, y el código C# debe usar estándares C#.

Para las interfaces públicas, debe seguir con el diseño de MS. NET framework directrices: "Convenciones de capitalización ".

Para los miembros no expuestos, entonces lo que usted y sus colegas puedan acordar.

Yo (y mi equipo) preferimos reservar mayúsculas iniciales para los nombres de clase.

¿Por qué? Los estándares Java se propagan, creo.

Desde Guía del Desarrollador de. NET Framework Convenciones de capitalización , Sensibilidad a Mayúsculas y minúsculas:

Existen las pautas de capitalización únicamente para facilitar los identificadores lee y reconoce. Carcasa no puede ser utilizado como un medio para evitar el nombre colisiones entre elementos de la biblioteca.

No asuma que toda la programación los idiomas distinguen entre mayúsculas y minúsculas. Son ni. Los nombres no pueden diferir según el caso solo.

Acabo de encontrar Estándares de Codificación para .Net.

La carcasa Pascal debe usarse para las propiedades. En cuanto a los nombres variables, algunas personas usan _ y algunas personas usan m_ y algunas personas solo usan casquillos de camello. Creo que mientras estés aquí, no debería importar.

Supongo que tienes que aguantar lo que dice el estándar de codificación para tu lugar de trabajo, por mucho que te disguste personalmente. Tal vez un día en el futuro usted será capaz de dictar sus propios estándares de codificación.

Personalmente me gusta que las bases de datos usen nombres de la forma "fish_name", "tank_id", etc. para tablas y campos, mientras que el código equivalente del modelo de base de datos sería "fishName" y "tankID". También me disgusta nombrar" _fooname "cuando" fooName " está disponible. Pero debo repetir que esto es subjetivo, y diferentes personas tendrán diferentes ideas sobre lo que es bueno y malo debido a su experiencia previa y educación.

En realidad, no hay una convención "estándar" sobre esto. Hay una guía editada de Microsoft en algún lugar, y como con cualquier otra guía de convención de nomenclatura, seguramente hay otra que la refuta, pero esto es lo que he llegado a entender como "convención estándar de carcasa de C#".

1. PerWordCaps en nombres de tipo (clases, enumeraciones), constantes y propiedades.
2. camelCase para variables locales realmente largas y variables protegidas/privadas
3. No ALL_CAPS nunca (bueno, solo en el compilador define, pero no en su código)
4. Parece que algunas de las clases del sistema usan nombres subrayados (_name) para las variables privadas, pero supongo que eso proviene del fondo del escritor original, ya que la mayoría de ellas vinieron directamente de C++. Además, tenga en cuenta que VB.NET no distingue entre mayúsculas y minúsculas, por lo que no podría acceder a las variables protegidas si extendiera la clase.

En realidad, FxCop hará cumplir algunas de esas reglas, pero (AFAIK) ignora cualquier ortografía se usa para variables locales.

Me gustan las convenciones de codificación establecidas en la especificación del proyecto Aardvark'd

Ese ejemplo de.NET que publicaste era una función. El "estándar" adoptado para métodos/funciones es un camel-case (o Pascal, si quieres llamarlo así).

Me quedo con camel case donde puedo. Le permite saber fácilmente la diferencia entre una variable y un método.

Además, soy fanático de colocar un subrayado delante de las variables de clase locales. Por ejemplo: _localVar.

El día en que deje de programar - es cuando Microsoft hará camelCase en C# como estándar. Porque mi lógica adulta tiene muchas razones para PascalCase, a diferencia de la lógica de kid, a quién le importa solo nombres más cortos o más fáciles de escribir.

Y por cierto: camelCasing proviene principalmente del estilo de biblioteca STD de C++, el lenguaje antiguo nativo heredado de C. Así que Java heredado de C++. Pero C# - es un lenguaje completamente nuevo-limpio y bello, con nuevas reglas. Oldfags debe programar en Java o C++, nueva generación las personas deben programar en C# - y nunca deben interactuar.

Considere este ejemplo: 1) PascalCase: lista.Capacidad.toString(); 2) camelCase: lista.capacidad.toString ();

En (1) tenemos CAMEL CASE a largo PLAZO!!! significa listCapacityToString. En (2) tenemos bullshit: listcapacitytoString.

Así es como leo. Y por qué camelCase es ilógico para sí mismo. Podría matar por PascalCase, nunca tocarlo, niños de cualquier edad.

Microsoft-para siempre o hasta que usen PascalCase.

Lo que tú prefieras es lo que importa, obviamente adhiriéndote al estándar del equipo principalmente. En privado codifica como quieras, no afecta al producto terminado si nombraste tu variable someVariable o someVariable.