Denominación: ¿Por qué las constantes con nombre deben estar todas en mayúscula en C++/Java?

Question

Sé que para C++ y Java es una convención de nomenclatura bien establecida, que las constantes deben escribirse todas en mayúscula, con guiones bajos para separar las palabras. Como esto (Java ejemplo):

public final static Color BACKGROUND_COLOR = Color.WHITE; 
public final static Color TEXT_COLOR = Color.BLACK; 

Esta convención de nomenclatura es fácil de entender y de seguir, pero me pregunto, ¿por qué elegir esta convención sobre el nombramiento-convención normal para las variables:

public final static Color backgroundColor = COLOR.WHITE; 
public final static Color textColor = COLOR.BLACK; 

Parece que no hay necesidad de cambiar el aspecto de las constantes. Si queremos asignarles un valor, el compilador evitará esto de todos modos. En realidad, crea problemas, si más adelante la constante se cambiará a una variable adecuada (porque los colores se pueden configurar, por ejemplo).

Entonces, ¿cuál es la razón última para escribir constantes con nombre todo en mayúsculas? Razones históricas?

Answer 1

Probablemente usted tiene la razón. Las computadoras y los compiladores (especialmente) no eran tan rápidos como hoy.

Joel Spolsky mencionó en one of his essays lo impresionado que estaba con el tiempo de compilación de la nueva versión de Turbo Pascal.

Recuerdo cuando compilación de programa no demasiado grande (10-20KLOC) con superposiciones en Turbo Pascal 5.0 en el PC XT 10MHz tomó unos 20 minutos ...

supongo que la espera de compilación para detectar el error no fue aceptable.

Y una convención como esa ayuda a evitar errores y pérdida de tiempo durante la compilación incompleta.

Answer 2

puedo imaginar que inicialmente, en los días C, la gente poner en práctica "constantes" simbólicamente, mediante el pre-procesador:

typedef unsigned int Color; 
#define BACKGROUND_COLOR 0xffffff 

Tales "constantes" son literales simplemente prettified, y como tales no se comporten del todo como variables. No se puede, por ejemplo, tomar la dirección de tal "constante":

Color *p = &BACKGROUND_COLOR; // Breaks! 

Por esta razón, tiene sentido disponer de ellos "se destacan", ya que realmente no son sólo "Variables no puede cambiar ".

Answer 3

Con las constantes mayúsculas, las fórmulas largas son mucho más fáciles de leer, no tiene que adivinar qué elemento puede variar y cuál no. Por supuesto, es solo una convención, pero útil.

Answer 4

Creo que no es un problema técnico sino psicológico. Las convenciones de nomenclatura no son para que el compilador las procese (a la computadora realmente no le importan los nombres) sino para que el programador que está navegando por el código tenga tanta información como sea posible con el mínimo esfuerzo requerido.

El uso de una convención de nomenclatura diferente le indica claramente al lector que lo que está leyendo es algo que se FIJA en tiempo de compilación y no necesita seguir el código para determinar dónde y cómo llegó el valor.

Answer 5

Si sé que algo es una constante, puedo consultarlo varias veces y saber que no cambiará.En otras palabras, sé que:

Color black = Colors.BLACK; 
foo(black); 
foo(black); 

es lo mismo que:

foo(Colors.BLACK); 
foo(Colors.BLACK); 

que puede ser útil conocer veces. Personalmente prefiero la convención de nombres de .NET, que consiste en utilizar el caso para las constantes Pascal (y métodos):

Foo(Colors.Black); 
Foo(Colors.Black); 

No soy un gran fan de shouty caso ... pero me gusta ser obviamente constantes constantes .

Answer 6

Es una solución para que sus herramientas de desarrollo no puedan detectar las propiedades de un identificador de manera conveniente.

Mucho me gusta la notación húngara.

Cuando su IDE mejora, no necesitará ninguna convención de nomenclatura, pero la que dicta que un nombre es información completa sobre lo que significa un identificador.

Incluso eso puede evolucionar: ¿por qué no crear un sistema de programación donde acaba de crear identificadores, y agregarle propiedades como "breve descripción", "tipo", ... Cuando llega la herramienta que puede hacer esto en un conveniente manera, estoy adentro. "Intentional Programming" es una pista.

Answer 7

Al programar, es importante crear un código que sea comprensible para los humanos. Tener convenciones de nombres ayuda a hacer esto. Esto es mejor cuando se mira el código que no se escribió y hace que el código sea más fácil de mantener porque es fácil de distinguir de constantes y variables.

Answer 8

Creo en C++ es una convención trasladada desde los días de uso del preprocesador a #definir valores constantes. En aquel entonces, se hizo para evitar que el preprocesador pisoteara todo su código fuente, ya que las convenciones usuales para la función C y los nombres de las variables los convertirían en mayúsculas o minúsculas.

Desde un punto de vista de C++, diría que es una mala idea hacer que sus constantes sean mayúsculas. He tenido que depurar más de un problema de compilación debido a esto, recuerde que el preprocesador C++ no sabe nada sobre los espacios de nombres y el alcance de los nombres, y con mucho gusto sustituirá lo que considere apropiado aunque sea inapropiado.

Answer 9

Las conversiones de codificación mejoran la legibilidad. No tienes que usar letras Java permite $ symbol por ejemplo.

public final static Color $$ = COLOR.WHITE; 
public final static Color $_ = COLOR.BLACK; 

Puede enumerar sus variables también, pero eso no significa que sea una buena idea. ;)

Answer 10

Creo que las constantes en mayúsculas son un mal legado de C. La lógica detrás es la misma que cuando se usan guiones bajos como prefijos para miembros privados. Esto es algo técnico que ya está expresado por palabras clave de Java como private o, en el caso de las constantes, static final.

Consulte también: http://weblogs.java.net/blog/2006/09/28/case-against-uppercases

Answer 11

En C (y luego C++), fueron escritos símbolos que se han definido con la directiva de preprocesador #define todo en tapas como una señal fuerte a los desarrolladores de que el código no era lo que parecía ya no se trata como un símbolo normal. Las constantes no existían inicialmente en K & R C (aunque const se trajo de C++ más tarde), por lo que los desarrolladores usaron #define en su lugar, de ahí los límites.

Por alguna razón, esto se convirtió en Java como "las constantes son límites", de ahí la convención equivocada actual (IMO).

Answer 12

Definitivamente es un problema técnico en Java. Considere lo siguiente:

import static com.test.constants.white; 
public class Foo { 
    void bar(){ 
    //String white = "black"; 
    String whatAmI = white; 
    } 
} 

¿Cuál es el valor de "whatAmI" antes y después de comentar la línea anterior?

Si el nombre de la constante tiene la misma convención que el nombre de la variable local, esto causará problemas con el código REAL. Las constantes siempre deben tener la convención MAYÚSCULA para evitar esto.

Answer 13

Básicamente, cuando la gente estaba enamorada de C, y C++ & Java eran nuevos o aún no se habían creado, las personas usaban mayúsculas para los nombres constantes del preprocesador, para indicar que en realidad no eran variables.

#define INT_CONST 4 
#define STRING_CONST "Yello." 
#define FLOAT_CONST 3.6122448 

Teniendo en cuenta que esta era la única manera de definir una verdadera constante en C (que sigue siendo posible cambiar const las variables si se sabe cómo), las constantes preprocesador como que se acaba de verse como constantes, y como tal el el significado de los nombres de mayúsculas pasó de constantes del preprocesador a simplemente constantes en general. Esto luego se trasladó a los idiomas posteriores, convirtiéndose en la práctica estándar "consts = capitales".

Otros idiomas tienen su propio estilo preferido, sin embargo, (por ejemplo, C# & .NET prefieren PascalCase), por lo que generalmente es mejor usar el estilo preferido si hay uno.

Answer 14

En realidad, la mayoría de las pautas de nomenclatura de C++ (incluyendo ISO, Boost, Sutter & Stroustrup y Google) desalientan fuertemente el nombramiento de constantes con mayúsculas. Esto se debe a que las macros también usan mayúsculas y pueden estar desperdigadas por todos los archivos de cabecera, creando potencialmente comportamientos extraños. La gente aún usa todas las mayúsculas porque aprenden del antiguo C/K & R o el antiguo código heredado. Sin embargo, en el código nuevo de Modern C++, debe evitar el uso de mayúsculas para cualquier cosa, excepto las macros.

La teoría de mi mascota sobre por qué existen todas las tapas es que en máquinas muy antiguas, el código se ingresaba directamente en código de máquina usando teclados numéricos. Cuando el lenguaje ensamblador llegó a la escena, solo usó mayúsculas porque el teclado en ese momento no estaba estandarizado y algunos teclados estaban limitados, por ejemplo, usando los mismos teclados numéricos para ingresar alfabetos como en los teléfonos con funciones. Esto se trasladó a muchos lenguajes antiguos como BASIC, que es todo en mayúsculas. Cuando los terminales reales estuvieron disponibles y los teclados comenzaron a estandarizarse, las personas comenzaron a usar casos mixtos sin reservas y todos los límites se reservaron para algo que es raro en la aparición como constantes en comparación con funciones y variables.

La mayoría de las pautas de C++ ahora acuerdan usar "k" como prefijo para constante seguido de nombre con subrayado o CamelCase. Yo personalmente prefiero kCameCase porque permite distinguir fácilmente de las variables que se nombran con under_scores.

const float kFixedRadius = 3.141; 

Answer 15

No utilice ALL_CAPS para las constantes sólo porque constantes utilizadas como macros.

Este quote de C++ Core Guidelines lo resume todo.

Answer 16

Esto es puramente para ayudar al programador a entender lo que está mirando de un vistazo. Es útil saber que se usa una constante para que el valor no cambie independientemente de cómo se refiera a él.

No hay realmente una razón con respecto al lado del compilador. Las convenciones de nombres son puramente eso, convenciones, no restricciones realmente técnicas.