¿Por qué las constantes no están todas en mayúsculas en .Net?

Las convenciones de nomenclatura de Microsoft para .Net ponen constantes en Pascal Case. De hecho, explícitamente nos dice que debemos evitar el uso de mayúsculas para constantes:¿Por qué las constantes no están todas en mayúsculas en .Net?

También podría tener que sacar provecho identificadores para mantener la compatibilidad con, símbolo no administrado existente esquemas, donde todos los caracteres en mayúsculas a menudo se utilizan para enumeraciones y valores constantes. En en general, estos símbolos no deben ser visibles fuera del ensamblaje que los utiliza.

De MSDN.

En SO encontré algunas preguntas sobre el tema, como esta one, pero no pude encontrar una justificación. Entonces, ¿alguien sabe o tiene una referencia que señala por qué MS eligió esta convención?

Fuente

2010-09-23 Bruno Brant

PORQUE TODO MAYÚSCULAS es difícil de leer y es destinado para las precompilador, QUE .NET doesn' T EVEN TENGO. –

Además, es feo. –

Bien, lo convertiré en una respuesta oficial. –

Es solo una guía de estilo. Los lenguajes de programación han comenzado a recomendar e impulsar las convenciones de formato para que el código sea más legible.

Además, los símbolos que se sustituyen por el preprocesador merecen una atención especial: viven fuera/delante del sistema de tipos y pueden no ser lo que parecen ser. Las constantes son solo constantes, no cambiarán durante la compilación o el tiempo de ejecución.

Fuente

2010-09-23 22:42:59 user318904

Si piensa en el historial, se usó mayúscula para los símbolos del preprocesador C, así que cuando C++ salió y tenía 'const', esos símbolos se mantuvieron en mayúsculas y minúsculas. C# y Java provienen de C++, por lo que siguen la convención de C++. –

En una nota lateral, no olvidemos que un 'const' es puramente tiempo de compilación mientras que' static readonly' está allí en tiempo de ejecución, por lo que solo el primero está permitido como valor predeterminado en C# 4. –

En segunda lectura , Tengo algo que elegir: el propósito de nombrar estándares y convenciones de formato no es solo hacer el código más legible sino hacerlo mutuamente inteligible. No hay una gran razón por la cual .NET recomienda MixedCase para los métodos en lugar de camelCase, pero si todos usan la misma de estas dos opciones, podemos leer el código del otro sin confundirnos ni molestarnos. Es como conducir en el lado derecho de la calle en lugar de la izquierda: realmente no importa, siempre y cuando todos elijan el mismo lado. –

PORQUE TODO EL MAYORDOMO ES FEO Y DIFÍCIL DE LEER Y ESTÁ DISEÑADO PARA EL PRECOMPILER, QUE .NET NO TAMBIÉN TIENE.

Además, Bill Gates lo quiere así, y el dinero nunca está mal.

Fuente

2010-09-23 22:43:18

Robó lo "feo" de Bennor; dando crédito. –

Y con Resharper (incluso VS) puede escribir MCVTNC para MyConstantValueThatNeverChanges, pero eso no funcionará para todos los topes. – PostMan

No creo que el acrónimo funcione en la lista de selección, al menos no para VS 2008. –

Microsoft no sigue sus propias reglas porque si reflexiona sobre las nuevas clases System.Threading.Tasks en C# 4 YOU_WILL_FIND_LOTS_OF_CAP_CONSTANTS.

Es una cosa de estilo. Personalmente no me importa. Solo sé consistente.

Fuente

2010-09-23 23:05:59

Es cierto; si nos fijamos en .Net internal, también encontramos muchos 'm_' usos, a pesar de ser malvado, prohibido la notación húngara. –

Decir que todas las mayúsculas es fea y, por lo tanto, no se debe utilizar es límite en la lógica infantil. Viene de personas quejándose de aquello a lo que no están acostumbrados.

Pasando de Java a C, comencé a usar guiones bajos entre palabras en nombres de variables y funciones. camelCase es extremadamente feo para mí ahora. Pero todavía uso camelCase para C++/Java sin quejarme porque es convección.

Si no puede hacerse flexible, la programación se convertirá en una amante dura. Esa es la habilidad de un programador.

Fuente

2011-01-06 02:32:53 Pizzach

No, es objetivamente malo: mayúsculas es simplemente difícil de leer. Comencé con mayúsculas porque esa es la única opción bajo EBCDIC. Ahora que tenemos idiomas con mayúsculas y minúsculas que usan ASCII, tenemos mejores opciones. –

@Steven: Tengo que estar en desacuerdo. Pizzach tiene razón: ALL_UPPER es solo texto, y no he oído hablar de una estadística que pruebe que es más difícil de leer que un caso pequeño. Me gustaría hacer una sola nota rápida, tener guiones bajos para separar las palabras cuesta un personaje más en la palabra, por lo que tenemos un código "más amplio" o "más largo", lo cual es malo. –

@ Bruno: las letras mayúsculas tienen una forma más similar que las minúsculas, por lo que son más difíciles de leer. Para citar a Wikipedia, "sin embargo, largos tramos de texto de alfabeto latino en mayúsculas son más difíciles de leer debido a la ausencia de los ascendentes y descendentes que se encuentran en minúsculas, lo que puede ayudar al reconocimiento". –

Igual que un BTW - EBCDIC es la versión extendida de BCD (decimal codificado en binario), y como tal ciertamente es compatible con minúsculas. Son las máquinas antiguas de IBM de los años 60 y anteriores (y otras) que no incluían minúsculas.

(Y, por supuesto, los ordenadores personales tempranas como el TRS-80 no tenían minúsculas, tampoco)

Fuente

2011-01-19 06:41:02

Tiene razón: EBCDIC es compatible con minúsculas. Sin embargo, por lo que puedo recordar, las máquinas de tarjetas perforadas que utilicé con la IBM 370 no ofrecían ninguna forma de ingresar caracteres en minúsculas. –

¿Por qué las constantes no están todas en mayúsculas en .Net?

Respuesta

Cuestiones relacionadas