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

Question

He estado discutiendo con mis compañeros de trabajo sobre la caja de Pascal (caja superior de camello) frente a la inferior CamelCasing. Se utilizan para la caja inferior del camello para todo, desde nombres de tabla de bases de datos SQL para nombres de propiedad en el código C#, pero me gusta Pascal carcasa mejor, la caja inferior del camello para las variables y la carcasa Pascal inmuebles:

string firstName; 
public string FirstName { 
... 
} 

sino que se utilizan a esto:

string _firstname; 
public string firstName { 
... 
} 

trato de mantenerse al día con su "estándar" por lo que el código es el mismo pero simplemente no me gusta.

que he visto que al menos el marco .NET utiliza esta convención y así es como trato de mantener mi código, ej .:

System.Console.WriteLine("string") 

¿Qué usas/prefieren y por qué? Lo siento si alguien más hizo esta pregunta, pero busqué y no encontré nada.

Actualización: He dado un ejemplo de método y no una propiedad, pero es lo mismo. Como dije en el primer párrafo, mis colegas usan la convención de Pascal para todo (variables, métodos, nombres de tablas, etc.)

Answer 1

Utilizo lo que usa el Framework, ya que es la mejor práctica de facto. Sin embargo, siempre que el código de su empresa sea consistentemente usando su estilo, entonces es mejor que se acostumbre a él. Si cada desarrollador tiene su propio estándar, entonces no hay ningún estándar.

Answer 2

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

¿Por qué? Estándares de Java que se propagan, creo.

Answer 3

La carcasa Pascal se debe usar para Propiedades. En lo que respecta a los nombres variables, algunas personas usan _ y algunas personas usan m_ y algunas personas simplemente usan la carcasa de camello. Creo que mientras seas consecuente aquí, no debería importar.

Answer 4

Ese ejemplo de .NET que publicó fue una función. El "estándar" adoptado para métodos/funciones es un camel-case con mayúscula (o Pascal, si quiere llamarlo así).

Me pego a la caja de camello donde puedo. Le permite conocer fácilmente la diferencia entre una variable y un método.

Además, soy un fan de pegar un guión bajo delante de las variables de clase locales. P. ej .: _localVar.

Answer 5

Para interfaces públicas, debe seguir con las directrices de diseño de .NET Framework : "Capitalization Conventions".

Para miembros no expuestos, lo que sea que usted y sus colegas puedan estar de acuerdo.

Answer 6

Supongo que tiene que aguantar lo que dice el estándar de codificación para su lugar de trabajo, por mucho que le desagrade personalmente. Quizás algún día en el futuro pueda dictar sus propios estándares de codificación.

Personalmente, me gustan las bases de datos para usar 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".Tampoco me gusta el nombramiento de "_fooname" cuando está disponible "fooName". 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 y educación previas.

Answer 7

Un enlace al design guidelines oficial podría ayudar. Específicamente, lea la sección en Capitalization styles.

En el gran esquema de las cosas, Pascal vs Camel no importa demasiado y no es probable que convenzas 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 coherente dentro de una base de código determinada.

Estoy contento siempre y cuando no estés usando el húngaro.

Answer 8

En realidad, no existe una convención "estándar" sobre esto. Hay una guía editada por Microsoft en alguna parte, 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 tripa C#".

1. PerWordCaps en nombres de tipos (clases, enumeraciones), constantes y propiedades.
2. camelCase para las variables locales muy largas y las variables protegidas/privadas
3. Sin ALL_CAPS vez (bueno, sólo en compilador define, pero no en su código)
4. Parece algunas de las clases de sistemas usan nombres subrayados (_name) para variables privadas, pero supongo que proviene de los antecedentes del escritor original, ya que la mayoría de ellos provienen directamente de C++. Además, tenga en cuenta que VB.NET no distingue entre mayúsculas y minúsculas, por lo que no podrá acceder a las variables protegidas si amplía la clase.

En realidad, FxCop aplicará algunas de esas reglas, pero (AFAIK) ignora cualquier ortografía que use para las variables locales.

Answer 9

me gusta las convenciones de codificación establecidos en la especificación Aardvark'd proyecto

Answer 10

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

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 C# contra el estándar. StyleCop se adhiere a su estilo PascalCase.

Llevar gente a StyleCop (o cualquier otro estándar) puede ser difícil, es todo un obstáculo, y StyleCop es bastante exhaustivo. Pero el código debe tener un estándar uniforme, y un estándar personal es mejor que ninguno, el estándar de la compañía es mejor que uno personal, y un estándar de la industria es el mejor de todos.

Es mucho más fácil convencer a las personas cuando comienza un proyecto: se está formando un equipo y no hay un código que convertir. Y puede poner herramientas (FxCop, StyleCop) en su lugar para romper la construcció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 los estándares C#.

Answer 11

De programador de .NET Framework Guía Capitalization Conventions, mayúsculas y minúsculas:

Las directrices de capitalización existe solamente para hacer más fácil a los identificadores leer y reconocer. La carcasa no puede ser utilizada como un medio para evitar el nombre colisiones entre los elementos de la biblioteca.

No asuma que todos los lenguajes de programación distinguen mayúsculas de minúsculas. Son no. Los nombres no pueden diferir por el caso solos.

Answer 12

Acabo de encontrar Coding Standards for .Net.

Answer 13

El día en que dejé de programar, es cuando Microsoft fabrica CamelCase en C# como estándar. Debido a que mi lógica de crecimiento tiene muchas razones para PascalCase, a diferencia de la lógica para niños, a quién le importa solo nombres más cortos o más fácil de escribir.

Y BTW: CamelCasing proviene principalmente del estilo de la biblioteca C++ STD, el antiguo lenguaje nativo heredado de C. Por lo tanto, Java se hereda de C++. Pero C# - es un lenguaje completamente nuevo - limpio y bello, con nuevas reglas. Oldfags debe programar en Java o C++, las personas de nueva generación deben programar en C# y nunca deben interactuar.

Considere este ejemplo: 1) PascalCase: list.Capacity.ToString(); 2) CamelCase: list.capacity.toString();

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

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

Microsoft - por siempre o hasta que usen PascalCase.

Answer 14

Lo que prefiera es lo que importa, obviamente se adhiere al estándar del equipo principalmente. En privado, usted codifica como quiera, no afecta el producto final, ya sea que haya nombrado alguna variable como Variable o AlgunaVariable.