notacion - Naming: ¿Por qué las constantes con nombre deben estar todas en mayúscula en C++/Java?

nombrado de variables métodos y constantes

Question

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

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

Esta convención de nombres es fácil de entender y seguir, pero me pregunto por qué elegir esta convención de nomenclatura sobre la convención de nomenclatura normal para 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 en mayúsculas? Razones históricas?

Answer 1

No use ALL_CAPS para constantes solo porque las constantes solían ser macros.

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

Answer 2

Básicamente, cuando las personas estaban enamoradas de C, y C ++ y Java eran nuevas 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 forma real de definir una constante verdadera en C (aún es posible cambiar las variables const si sabes cómo), las constantes del preprocesador como ese solo se veían como constantes, y como tal el significado de los nombres de mayúsculas cambió desde constantes del preprocesador hasta simplemente constantes en general. Esto luego se trasladó a los idiomas posteriores, convirtiéndose en la práctica estándar "consts = capitales".

Sin embargo, otros lenguajes tienen su propio estilo preferido (por ejemplo, C # y .NET prefieren PascalCase), por lo que generalmente es mejor usar el estilo preferido si hay uno.

Answer 3

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

Answer 4

Creo en C ++ es una convención que se lleva de la época en que se usa el preprocesador para 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 el punto de vista de C ++, diría que es una mala idea hacer que tus 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 5

Creo que las constantes en mayúsculas son una mala herencia 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 constantes, static final .

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

Answer 6

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 está diciendo claramente al lector que lo que está leyendo es algo que se FIJA en el momento de la compilación y no necesita seguir el código para determinar dónde y cómo llegó el valor allí.

Answer 7

Cuando se programa, 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

De hecho, la mayoría de las pautas de nomenclatura de C ++ (incluidos ISO, Boost, Sutter & Stroustrup y Google) desalientan rotundamente las constantes de denominación 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 todavía usa todas las mayúsculas porque aprenden del viejo C / K & R o 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.

Mi teoría favorita de por qué todas las mayúsculas existen 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 por nombre con guión bajo 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 9

Definitivamente es un problema técnico en Java. Considerar:

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 descomentar 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 10

En C (y luego en C ++), los símbolos que se definieron con la directiva preprocessor #define se escribieron en mayúsculas como una señal fuerte para los desarrolladores de que el código no era como parecía y no se consideraba 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 utilizaron #define lugar, de ahí los topes.

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

Answer 11

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

Al igual que la notación húngara.

Cuando su IDE mejore, no necesitará ninguna convención de nomenclatura, sino 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 de una manera conveniente, yo '' m in. La " Programación intencional " es una pista.

Answer 12

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

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

También puedes enumerar tus variables, pero eso no significa que sea una buena idea. ;)

Answer 13

Me imagino que inicialmente, en los días C, las personas implementarían "constantes" simbólicamente, usando el pre-procesador:

typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff

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

Color *p = &BACKGROUND_COLOR; // Breaks!

Por esta razón, tiene sentido que se "destaquen", ya que en realidad no son solo "variables que no puedes cambiar".

Answer 14

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

Joel Spolsky mencionó en uno de sus ensayos lo impresionado que estaba con el tiempo de compilación de la nueva versión de Turbo Pascal.

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

Supongo que esperar a que la compilación detecte el error no era aceptable.

Y una convención como esa ayuda a evitar errores y tiempo perdido durante la compilación incompleta.

Answer 15

Si sé que algo es una constante, puedo referirme a él 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);

Eso puede ser útil para saber algunas veces. Personalmente prefiero la convención de nomenclatura .NET, que es usar el caso de Pascal para las constantes (y métodos):

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

No soy un gran admirador del caso shouty ... pero me gusta que las constantes sean evidentemente constantes.

Answer 16

Esto es puramente para ayudar al programador a comprender lo que está mirando de un vistazo. Ayuda saber que se está utilizando 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 compilador de las cosas. Las convenciones de nombres son puramente eso, convenciones, no restricciones realmente técnicas.