Guía de estilo de Google en C ++. Parte 1

Parte 1. Introducción
...
Parte 8. Nombramiento
Parte 9. Comentarios
...


Al escribir código, todos usamos las reglas de diseño de código. A veces se inventan sus propias reglas, en otros casos, se utilizan guías de estilo confeccionadas. Aunque todos los programadores de C ++ leen en inglés más fácilmente que en su idioma nativo, es más agradable tener un manual en este último.
Este artículo es una traducción de parte de la guía de estilo de Google en C ++ al ruso.
Artículo original (fork en github), traducción actualizada .
Esta es la parte introductoria de la guía, que aborda las preguntas generales de "¿Por qué?"
Además, después de la traducción habrá varias respuestas a posibles preguntas.

Entrada

C ++ es uno de los principales lenguajes de programación utilizados en proyectos de código abierto de Google. Se sabe que C ++ es un lenguaje muy poderoso. Sin embargo, es un lenguaje complejo y, si se usa incorrectamente, puede ser un hervidero de errores, lo que dificulta la lectura y el mantenimiento del código.

El objetivo de esta guía es administrar la complejidad del código al describir en detalle cuánto vale (o no vale la pena) escribir código C ++. Las reglas de esta guía simplificarán la administración del código y aumentarán el rendimiento de los codificadores.

Estilo : convenciones seguidas de código C ++. El estilo es más que formatear un archivo con código.

La mayoría de los proyectos de código abierto desarrollados por Google siguen esta guía.

Nota: esta guía no es un tutorial de C ++: se supone que está familiarizado con el lenguaje.

Objetivos de la guía de estilo

¿Por qué se necesita este documento?

Hay varios objetivos principales de este documento, por qué internos, reglas individuales subyacentes. Con estos objetivos, puede evitar largas discusiones: por qué las reglas son y por qué deben seguirse. Si comprende los objetivos de cada regla, es más fácil para usted aceptarlos o rechazarlos, evaluar alternativas al cambiar las reglas por usted mismo.

Los objetivos de gestión son los siguientes:

• Las reglas deben valer la pena el cambio.
  
  
  • Los beneficios de usar un solo estilo deberían superar la insatisfacción de los ingenieros al recordar y usar las reglas.
  • La ventaja se evalúa en comparación con la base del código sin la aplicación de reglas, por lo que si su gente aún no aplica las reglas, el beneficio será muy pequeño.
  • Este principio explica por qué faltan algunas reglas: por ejemplo, goto viola muchos principios, pero prácticamente no se usa, por lo tanto, la Guía no lo describe.
• Optimizado para leer, no para escribir
  
  
  • Nuestro código base (y la mayoría de los componentes individuales de él) se utilizará durante mucho tiempo. Por lo tanto, se pasará mucho más tiempo leyendo este código que escribiendo.
  • Claramente nos importa que nuestros ingenieros tengan un lego para leer, mantener y depurar código. “Dejar el código de depuración / registro” es una de las consecuencias: cuando un código funciona de forma “extraña” (por ejemplo, al transferir la propiedad de un puntero), la presencia de sugerencias de texto puede ser muy útil ( std :: unique_ptr muestra claramente la transferencia de propiedad).
• Escribe un código similar a uno existente
  
  El uso de un estilo único en una base de código le permite cambiar a otros problemas más importantes.
  
  Además, un estilo único promueve la automatización. Y, por supuesto, el formato automático del código (o la alineación de #include ) funciona correctamente si cumple con los requisitos de la utilidad. En otros casos, solo se usa uno (el más adecuado) del conjunto de reglas, y cierta flexibilidad en el uso de las reglas permite a las personas discutir menos.
• Escriba un código similar al utilizado en la comunidad C ++ (si es posible)
  
  La consistencia de nuestro código con el código C ++ de otras organizaciones y comunidades es muy útil. Si las características de C ++ estándar o los modismos aceptados del lenguaje facilitan la escritura de programas, esta es una ocasión para usarlos. Sin embargo, a veces el estándar y los modismos están mal adaptados a la tarea. En estos casos (como se describe a continuación) tiene sentido limitar o prohibir el uso de algunas características estándar. En algunos casos, se crea su solución, pero a veces se usan bibliotecas externas (en lugar de la biblioteca estándar de C ++) y reescribirlo a su propio estándar es demasiado costoso.
• Evitar estructuras inesperadas o peligrosas.
  
  C ++ tiene enfoques evidentes e incluso peligrosos. Algunos estilos de codificación limitan su uso, ya que su uso conlleva grandes riesgos para la corrección del código.
• Evite construcciones que el programador promedio de C ++ considere abstrusas y difíciles de soportar
  
  En C ++, hay características que generalmente no son bienvenidas debido a la complejidad del código.
  Sin embargo, en el código de uso frecuente, el uso de construcciones difíciles está más justificado debido al uso repetido, así como las nuevas partes del código serán más claras.
  
  En caso de duda, consulte con el líder del proyecto.
  
  Esto es muy importante para nuestra base de código, ya que los propietarios del código y un equipo de soporte cambian con el tiempo: incluso si todos entienden el código ahora, las cosas pueden cambiar en unos pocos años.
• Considere la escala del código
  
  Con una base de código de más de 100 millones de líneas y miles de ingenieros, los errores y las simplificaciones pueden ser costosos. Por ejemplo, es importante evitar ensuciar el espacio de nombres global: las colisiones de nombres son muy difíciles de evitar en una base de código grande si todo se declara en el espacio de nombres global.
• Optimizar según sea necesario
  
  La optimización del rendimiento a veces es más importante que seguir las reglas de codificación.

La intención de este documento es proporcionar la guía más comprensible con restricciones razonables. Como siempre, nadie canceló el sentido común. Con esta especificación, queremos establecer convenciones para toda la comunidad de Google en C ++, no solo para equipos o personas individuales. Sea escéptico ante los diseños astutos o inusuales: la falta de limitación no siempre tiene una resolución. Y si no puedes decidir por ti mismo, pregúntale al jefe.

Versión C ++

Ahora el código debe cumplir con C ++ 17, es decir Las características de C ++ 2x no son deseables. En el futuro, el manual se ajustará para las versiones más nuevas de C ++.

No use extensiones personalizadas .

Considere la compatibilidad con otros entornos si tiene la intención de usar C ++ 14 y C ++ 17 en su proyecto.

Nota: los enlaces pueden conducir a secciones del manual que aún no se han traducido.

Algunas respuestas / comentarios:

- ¿Por qué transferir?

Personalmente, me siento más cómodo con el liderazgo ruso. También es mejor discutir los cambios en la guía de estilo con el texto en ruso.

- ¿Por qué google? ¿Hay más (o menos) populares ...?

La compañía es bastante conocida, el liderazgo no es muy grande (puede traducirlo sin esfuerzo por una sola persona), cumple con las funciones requeridas: esta guía está de moda

- Pero el manual de Google declara el uso de obsoletos (...), el rechazo de tan útil (...)! Por qué

Según tengo entendido, este documento es una propuesta. Usarás algo, cambiarás algo, esto está permitido. El liderazgo es una buena base.