¿Existe una convención de capitalización común en C ++? [cerrado]

Hago mucho trabajo en Python y Java, y ambos lenguajes tienen convenciones bastante comunes (aunque no universales) sobre cómo se deben usar las mayúsculas en los identificadores: ambos se usan PascalCasepara nombres de clase y ALL_CAPSpara constantes "globales", pero para otros identificadores un muchos usos de código Java, mixedCasemientras que muchos usos de código Python underscore_delimiters. Sé que ningún idioma o biblioteca impone una capitalización en particular, pero descubrí que cuando me apego a las convenciones estándar para el idioma que estoy usando, mi código parece mucho más legible.

Ahora estoy comenzando un proyecto en C ++, y me gustaría aplicar la misma idea. ¿Hay alguna convención más común para la capitalización que deba conocer?

¿Hay alguna convención más común para la capitalización que deba conocer?

C ++ se basa en C, que es lo suficientemente viejo como para haber desarrollado un montón de convenciones de nomenclatura para cuando se inventó C ++. Luego, C ++ agregó algunos, y C tampoco ha estado inactivo pensando en nuevos. Agregue a eso los muchos lenguajes derivados de C, que desarrollaron aún más las convenciones de nomenclatura de C de su inventor, hasta el punto de volver a fertilizar en C y C ++ ... En otras palabras: C ++ no tiene una, sino muchas de esas convenciones.

Sin embargo, si está buscando la convención de nomenclatura única , también podría mirar la convención de nomenclatura de la biblioteca estándar , porque esta es la única que todos los desarrolladores de C ++ tendrán que conocer y estar acostumbrados.

Sin embargo, lo que sea que use la regla más importante es: ¡ Sea consistente!

Curiosamente, aunque comencé con una combinación de PascalCase y camelCase, y participé en numerosos proyectos con convenciones de nomenclatura aún más numerosas, a lo largo de los años descubrí que me atasqué cada vez más con la convención de biblioteca estándar. No me preguntes por qué.

Primero aceptemos que ALL UPPERCASE es una monstruosidad y debe minimizarse.

Por lo tanto, en C y C ++ se usa como una convención para macros, y solo para macros, porque las macros son igualmente feas, por no decir mal.

Los primeros C no tenían constante, por lo que las constantes debían expresarse como macros. Además, en aquellos primeros días, los programas eran mucho más cortos, por lo que las prácticas que hoy no son buenas podrían usarse (por ejemplo, el IIRC Brian Kernighan escribió código con muchas macros no mayúsculas). Y también, en aquellos días existían teclados que no tenían letras minúsculas; Usé uno de estos, en la computadora noruega Tandberg EC-10, alrededor de 1980 o 1979, creo que era.

Entonces, Java recogió la convención en mayúscula para constantes desde principios de C. Mientras tanto, y tal vez incluso antes de eso (no estoy seguro de la cronología aquí), C obtuvo constantes. Sin embargo, aunque, por supuesto, algunos / muchos programadores de C estaban estancados en la convención anterior por necesidad de constantes como macros en mayúsculas, los programadores de C ++ eran más sensibles.

El gran problema hoy en día es cuando a las personas primero se les enseña Java, o C (con convenciones de la edad media) primero, y luego vienen a C ++, llevándose esa convención en mayúscula.

Entonces,

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Bueno, podrías haber pensado que mencioné los teclados solo en mayúsculas en broma. Oh no. Porque esa es simplemente la limitación de tecnología más antigua y arcaica que ha impulsado las convenciones de nomenclatura, o al menos ha afectado lo equivocado / correcto que parecían. Luego, surgió el problema de la transmisión en serie de 7 bits, que causó los problemas correspondientes con los códigos de caracteres (codificaciones de caracteres de newspeak) utilizados, lo que significaba que tenía que restringirse a las letras del alfabeto inglés, de la A a la Z.

En realidad, recomiendo seguir haciendo eso. Ahí es donde estamos! No hemos llegado más lejos.

En este momento, a partir de 2011, C ++ estándar admite nombres Unicode generales (y lo ha hecho desde 1998), mientras que las implementaciones reales de C ++ no. En particular, el compilador de g ++ tiene un carácter nacional cuestionado. Se deriva de esa limitación tecnológica de la edad oscura.

Entonces,

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Finalmente, sobre el tema de guiones bajos versus letras mayúsculas intercaladas,

• Reserve un formulario fácilmente reconocible para los nombres de tipo.
• Reserve TODAS LAS MAYÚSCULAS para macros.
• Se consistente.

Creo que es eso, en realidad, excepto por reglas como "generalmente evitar el nombre de una sola letra, excepto (loop, template param, blah blah)" y "evitar usar l, fácilmente confundido con 1" y "evitar O mayúscula, fácilmente confundido con 0 ". Además, por supuesto, evite usar nombres reservados como comenzar con un guión bajo seguido de mayúscula, que contiene dos guiones bajos sucesivos, o comenzar con un guión bajo y estar en el espacio de nombres global.

Saludos y hth

Por lo general, tiendo a mantener la convención que más veo en las bases de código existentes para el lenguaje. En el caso de C ++, generalmente veo camelCase. En el caso de Ruby o PHP, generalmente veo stuff_like_this.

Sin embargo, en términos realistas, lo más importante es que elija una convención de estilo que no sea totalmente una locura (dOnT_dO_tHiS) y sea coherente con ella. Haz que el estilo no cambie a lo largo del código para un proyecto en particular. Si está trabajando en un proyecto existente, querrá seguir el estilo que ya existe.

Bueno, hay sistemas húngaros que es realmente común incluso ahora, pero prefiero cortarme la garganta que recomendarlo. Apps Hungarian es mejor, ya que sus marcas anotativas son realmente indicativas de semántica, aunque creo que es demasiado entusiasta con las abreviaturas cuando una palabra corta sería suficiente. (Para usar el ejemplo de esa página de Wikipedia, ¿ rwpor qué usar para fila cuando rowsolo tiene un carácter más? No es que haya una escasez global de vocales).

Sin embargo, de manera realista, lo más importante es seguir las convenciones de las personas con las que está trabajando . De Verdad. La mayoría de las convenciones funcionan lo suficientemente bien, especialmente si se usan de manera consistente. La inconsistencia es peor (incluso más que Systems Hungarian, que odio). Y si estás solo, usa lo que quieras.

Por lo que he visto, varía entre proyectos.

Los guiones bajos incrustados son probablemente más tradicionales / más utilizados en C en Unix. La biblioteca estándar también sigue esto, por lo que casi con certeza debería tratarse como predeterminado, a menos que haya suficiente código existente usando otra convención para forzar absolutamente el uso de esa otra convención.

Windows (por ejemplo) usa el caso camel para la mayoría de sus funciones, por lo que algunas personas que desarrollan para Windows hacen lo mismo. Esto también es bastante común entre las personas que están más acostumbradas a otros lenguajes e intentan tratar C ++ como si fuera una variante extraña de otra cosa.

He usado tanto la biblioteca estándar como el boost como referencias para las convenciones de nomenclatura. Sin embargo, hay un problema con esta solución.

La biblioteca estándar utiliza una convención de nomenclatura diseñada para intentar reducir las colisiones con su código. Parte de la solución es usar todas las letras minúsculas. De ahí el uso de guiones bajos en lugar de camelCase.

Encuentro que camelCase es legible. PascalCase se usa a menudo para los nombres de clase, ya que representa el equivalente de un nombre propio. Sin embargo, romperé esa regla para los functores que son más representativos de un verbo.

Intento no usar macros. Sin embargo, cuando lo hago, las macros están hechas para parecerse a funciones cuando pueden. También uso valores constantes o enumeraciones en lugar de constantes manifiestas, evitando aún más todas las mayúsculas. Normalmente prefijo estos símbolos con una 'k' para indicar que son constantes.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

Esta referencia describe una convención de nombres que es bastante similar a las que he visto utilizadas con éxito en al menos tres empresas para las que he trabajado en el pasado.

Contrariamente a una respuesta anterior, evitaría seguir la convención de nomenclatura de la Biblioteca estándar de C ++ en mi propio código, si no fuera por otra razón que evitar las colisiones de nombres con la Biblioteca estándar.

Esta respuesta SO anterior sobre un tema relacionado también puede ser de interés: /programming/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier