libreria - ¿Por qué el estilo de codificación STL/Boost C++ difiere tanto de los demás?

boost libreria

Question

Soy un programador de C ++ bastante novato, pero en mi experiencia limitada con el lenguaje, la mayoría de las pautas de estilo de C ++ (por ejemplo, las Pautas de estilo de Google C ++ ) van en contra de lo que se implementa en las bibliotecas stl y boost.

Por ejemplo, los nombres de clase en la biblioteca estándar de C ++ y Boost siempre están en minúscula, con guiones bajos que separan las palabras (por ejemplo, std::vector , boost::unordered_map , std::map::const_iterator ), mientras que la mayoría de las guías de estilo que he visto para C ++ tiende hacia un estilo CamelCase (por ejemplo, TcpConnection o Int32 ).

Lo mismo se aplica a los métodos también. La biblioteca estándar y Boost utilizan el mismo estilo para los métodos y funciones que para las clases (por ejemplo, std::map<>::get_equal("foo") ), mientras que la mayoría de las guías de estilo recomiendan pascalCase o CamelCase.

Si comparamos esto con un lenguaje como Ruby, donde la mayoría de los usuarios se adhieren a las convenciones utilizadas en las bibliotecas principales, parece extraño que exista tal diferencia entre las bibliotecas estándar de C ++ y el código de todos los demás.

¿Alguien sabe a que se debe esto?

EDITAR: Solo para aclarar, estoy hablando simplemente del estilo textual superficial (encuadernación, uso de guiones bajos, etc.) en lugar del estilo de implementación real.

Answer 1

Hay una buena razón al lado de Bjarne Stroustrup. Cuando usas functores quieres que se vean como funciones.

Pero con las guías de estilo de CamelCase, distingue Clases de Métodos y Funciones al usar Mayúsculas en el primer carácter de las Clases y en LowerCase en el primer carácter de un método.

Esto no es coherente con la programación de estilo de algoritmo c ++. Como no hay ninguna razón para distinguir un functor de una función, es preferible utilizar los estilos de codificación c ++ y stl cuando desee usar los functors (y normalmente lo desea).

Answer 2

Las únicas reglas que realmente se necesitan son aquellas diseñadas para prevenir problemas conocidos:

• Use ALL_CAPS (más guiones bajos y dígitos) para los nombres del preprocesador, y solo para los nombres del preprocesador. Puede ser difícil perseguir los problemas causados ​​por colisiones entre un identificador (supuestamente) no preprocesador y un nombre de preprocesador, aún más difícil de solucionar.
• Nunca inicie un identificador con un subrayado, y no tenga un subrayado doble en ninguna parte dentro de un identificador. Aquellos están reservados para la implementación.

Más allá de esto, sé coherente y no seas demasiado exigente. Los estándares de codificación deben tener en cuenta la regla # 0, que es "No se preocupe por las cosas pequeñas" Demasiados estándares de codificación sudan las cosas pequeñas.

En lo que respecta al estándar de C ++ de Google, no es el mejor. Es más de una C más o menos estándar. Se prohíbe pasar por referencia no constante, por ejemplo.

Answer 3

los guiones bajos y minúsculas fueron el estilo preferido por Bjarne Stroustrup en "El lenguaje de programación C ++". Si recuerdo correctamente, había hecho una declaración en la que se prefería subrayar los nombres, ya que era más legible para una comunidad internacional donde el inglés no es el idioma principal. No tengo idea si su opinión es cierta o no, pero supongo que ese es el origen.

Aquí hay un enlace a sus preguntas frecuentes donde se analiza este tema:

http://www.stroustrup.com/bs_faq2.html#Hungarian

Fragmento explicando lo que te interesó en particular:

Prefiero usar guiones bajos para separar palabras en un identificador (por ejemplo, element_count) en lugar de alternativas, como elementCount y ElementCount. Nunca use nombres con todas las letras mayúsculas (p. Ej., BEGIN_TRANSACTION) porque eso se reserva convencionalmente para macros. Incluso si no usa macros, alguien podría haber cubierto sus archivos de encabezado con ellos. Use una letra mayúscula inicial para los tipos (por ejemplo, Cuadrado y Gráfico). El lenguaje C ++ y la biblioteca estándar no usan letras mayúsculas, por lo que es int en lugar de Int y string en lugar de String. De esa manera, puedes reconocer los tipos estándar.