¿Debería mi equipo utilizar algún estándar de codificación común y bien considerado como base?

El equipo de I + D en el que estoy ha decidido adoptar un estándar de codificación. Recientemente nos hemos formado y tenemos muy poco código y tiempo de codificación común para basar nuestro documento de estándares / convenciones en lo que se ha desarrollado orgánicamente en nuestro equipo, y en buenos ejemplos de nuestro propio código, etc.

Ahora, cada uno de nosotros tiene algo de experiencia en lugares de trabajo pasados, aunque ninguno de nosotros está en el estado de decir "adoptemos aquí este documento completo que he encontrado adecuado para el tipo de trabajo que hacemos aquí" (*). Además, algunos de nosotros (incluido yo mismo) solo tenemos experiencia en lugares sin un estándar de codificación oficial, o escribiendo en diferentes idiomas en un entorno diferente (entorno de producción de lanzamiento semanal de alta presión en lugar de un trabajo de desarrollo más orientado a la investigación)

Por lo tanto, una de las opciones en las que he estado pensando es tomar un documento relativamente conocido y bien considerado, recortar lo que no nos interesa o hacer y hacer algunas modificaciones basadas en nuestras preferencias.

¿Es esta una práctica común? ¿Crees que es una buena idea? De ser así, ¿cuál sería un estándar de codificación razonable 'de referencia'? .)

Notas:

• Esperamos trabajar con C, C ++, OpenCL, CUDA, Python.
• Somos un equipo de 4 personas + gerente, se espera que crezca a unos 5-6 dentro de un año más o menos.
• En nuestra empresa, los equipos son casi completamente autónomos y, por lo general, no interactúan en absoluto (ni siquiera mediante el uso del código de los demás; el trabajo se realiza en proyectos completamente diferentes); así que no hay que hacer consideraciones a nivel de toda la empresa.
• En cuanto a las herramientas, en este momento lo que sabemos es que vamos a utilizar Eclipse , por lo que su formateador de código será al menos una herramienta. Ctrl + Shift + F ha sido mi amigo por mucho tiempo
• Cuando escribo Java, adopté la práctica de adherirme lo más estrictamente posible a la Java efectiva de Bloch . Ahora, ese no es un estándar de codificación, pero podría llamar a algunos ladrillos, cemento y mortero para un estándar de codificación. Estaba pensando en incluir algo así como parte de la 'mezcla' (teniendo en cuenta que no hacemos Java).
• Me refiero a las normas de codificación en el sentido más amplio de la palabra, por ejemplo, la adopción de propuestas formuladas en las respuestas a esta pregunta P.SE .
• He encontrado una gran lista de documentos de estándares de codificación C ++ ; tal vez debería minar que nuestra línea de base.
• (*) Eso no es del todo cierto, pero no quiero complicar esta pregunta con demasiados detalles.

Dicho de otra manera, está preguntando si debe poner en marcha los estándares de codificación de su equipo tomando prestados los estándares externos que haya encontrado. No parece que nadie en el equipo tenga opiniones muy fuertes (todavía) sobre cuáles deberían ser esos estándares.

Inequívocamente, la respuesta es sí.

Un estándar de origen externo es superior a nada. Mire las respuestas en " https://softwareengineering.stackexchange.com/q/84203/53019 " para ver algunas de las ventajas de tener un estándar. La consistencia y tener una base para cambiar son críticos desde su punto de vista.

También eche un vistazo a " Manejo de estándares de codificación en el trabajo (no soy el jefe) ", ya que entra en algunas de las dinámicas del equipo que su equipo debe tener en cuenta al seleccionar cuáles deberían ser los estándares. El equipo necesita ser dueño de su (s) estándar (s) de codificación para que todos cumplan voluntariamente con las restricciones que impone sobre cómo codifica cada persona.

Se vinculó a esta pregunta, pero vale la pena señalar la respuesta principal y su enfoque en comprender por qué los requisitos están establecidos. Si usa un estándar externo, será difícil para su equipo comprender la base de todos esos requisitos. Pero si acepta que están allí simplemente porque su equipo necesitaba algo para comenzar, entonces es fácil pasar a cambiar ese estándar externo a algo que funcione mejor para su equipo.

Tener cualquier estándar establecido le permite llenar las reglas de formato que usará con su IDE (Eclipse en su caso). " Ventajas y desventajas del reformateo de código forzado " entra en los beneficios para todos en el equipo por tener esa coherencia con el código en el que están trabajando, y le brinda la capacidad de reformatear fragmentos que puede pedir prestados de otros proyectos. Una ventaja adicional del uso de un estándar externo es que ya puede estar rellenado previamente en la parte de formato de código de su IDE.

Es probable que alguien del equipo se queje de una parte particular del estándar y lo culpe por el hecho de que haya utilizado un estándar externo como base. Pídales que lean:
- Odio uno de nuestros estándares de codificación y me vuelve loco, ¿cómo procesarlo?
- ¿Cómo superas tus propios sesgos de codificación cuando te entregan código heredado?
y luego se dan cuenta de que probablemente se habrían quejado de algo dentro del estándar, sin importar de dónde venga. En cuanto a la cantidad de equipos en los que he trabajado, aún no he visto un estándar que todos a) hayan apreciado universalmente yb) estén de acuerdo con cada parte del estándar. Vuelva a consultar algunos de los primeros enlaces para ver cómo lidiar con esas preocupaciones.

Anexo, usted preguntó sobre "cuál" debe usar. Específicamente no voy a responder eso, ya que cualquier respuesta está potencialmente afectada por las guerras de llamas alimentadas por la opinión. Sin embargo, puede mirar su IDE (Eclipse) y ver qué opciones proporciona como configuración estándar. También buscaría un poco y vería si hay proyectos que complementen su IDE y proporcione opciones de estándares adicionales para elegir. Correcto o incorrecto, esos estándares ya están completos para usted y pueden ahorrarle a su equipo una gran cantidad de trabajo en la configuración para todos.

Comenzaría con Python. Python tiene pautas de codificación que siguen casi todos los programadores de Python que existen. Forman parte de la documentación oficial llamada PEP8 .

C / C ++ es un gran desastre por razones históricas, pero dado que Python no lo es, te recomiendo que sigas la convención de nomenclatura de Python en C / C ++ también por razones de coherencia.

Ahora, para C ++, en realidad es más importante acordar modismos comunes y asegurarse de que todos entiendan el estilo moderno razonable de C ++ que cualquier guerra sobre convenciones de nombres. Debe comenzar con los estándares de codificación de C ++ y, desde los recursos en línea, asegúrese de leer las preguntas frecuentes de C ++ .

Ni siquiera puede discutir este tema sin hacer la distinción entre un estándar de codificación y un estándar de estilo de codificación .

Un estándar de codificación es un conjunto de reglas que definen qué mecanismos del lenguaje puede usar, cuáles no puede usar y cómo usarlos. En otras palabras, usted define un subconjunto del lenguaje utilizado, y / o un superconjunto, si el estándar de codificación aborda ciertas extensiones no estándar.

Un estándar de estilo de codificación solo se refiere a cuestiones estéticas: dónde colocar llaves y espacios, cómo nombrar identificadores, cómo colocar comentarios, etc.

Estas dos cosas diferentes pueden estar ubicadas en el mismo documento. Sin embargo, los estándares de codificación más serios no se refieren al estilo, los que recomiendo a continuación no. Muy probablemente porque el estilo de codificación es muy subjetivo y por lo tanto causa mucha fricción cuando las opiniones chocan.

Para C / C ++, los estándares de codificación con la mejor reputación son los de MISRA . Están diseñados principalmente para aplicaciones de seguridad / misión crítica, pero dado que la clave para hacer que los programas sean más seguros es eliminar y evitar errores, los estándares MISRA se aplican a cualquier rama de programación donde no se desean errores.

Los estándares de CERT también son bastante conocidos y están más sesgados hacia la programación de escritorio y la seguridad del software (en lugar de la seguridad). CERT tiene estándares para C, C ++, Java y Perl, y los estándares son gratuitos.

Comenzaría mirando MISRA y CERT, en lugar de algún estándar de garaje aleatorio que se encuentra en la web.

Usar un estándar existente como base para el suyo tiene varias ventajas. Su código probablemente será más similar al código externo, lo que facilitará la lectura / integración del código. Además, si elige un buen estándar, habrá sido examinado por expertos que hayan tenido buenas razones para decidir sobre sus reglas particulares. Mientras nadie en su equipo esté particularmente vinculado a un estándar, hay pocas razones para no usar un estándar existente como base para el suyo.

Si no está seguro de qué estándares de codificación usar, hay algunas primeras opciones obvias ideales. Sin ningún orden en particular:
1. Cualquiera que sea el estándar que ya sea compatible con su IDE. Esto es probablemente configurable.
2. Cualquiera que sea el estándar utilizado / recomendado por el autor de su compilador.
3. Cualquiera que sea el estándar utilizado / recomendado por el autor de su marco primario (si existe).
4. Cualquiera que sea el estándar utilizado / recomendado por el (los) autor (es) / diseñador (es) de su lenguaje de programación.
5. Cualquiera que sea el estándar utilizado / recomendado por una empresa muy grande.

Recomiendo a alguien con experiencia técnica que lea el estándar que esté utilizando como base para su propio estándar. Un buen estándar a menudo tendrá una justificación para cada regla, lo que lo ayudará a modificar el estándar para que se ajuste mejor a sus necesidades.

Un estándar generalmente ayuda a la comunicación y el mantenimiento. En mi opinión, debería estar sujeto a un toma y daca, especialmente en equipos pequeños, y debería evolucionar. Llamarlos pautas puede ayudar :-)

Echa un vistazo a las pautas de Google para inspirarte.

NO, no me molestaría, creo que el único beneficio sería que su equipo se mudara a un lugar donde también se usaran esos estándares, que no es lo que quiere que suceda :)

Los estándares solo están ahí para alentar una colaboración más fácil, por lo que si sabe que una macro #define siempre está en mayúscula, cuando vea un identificador en mayúscula en el código, tendrá una idea razonable de que es una macro. Del mismo modo, otras convenciones de nomenclatura o convenciones de estilo le recordarán a qué se enfrenta.

Creo que los estándares como la ubicación y el nombre del archivo son más útiles1 que los del código (después de todo, el código viene en todas las formas y tamaños, y todavía tiene que leerlo) mientras que no sabe que el archivo readme.txt está en / bin / doc / debug / release / documents es un verdadero dolor (como es un camino horrible, pero esa es otra historia).

Le recomendaría que haga sus propios estándares a medida que avanza. De esa manera, no solo obtienes los que te gustan, sino que también obtienes los que definitivamente son adecuados para ti, tu equipo y el trabajo que haces. Si decide que no le importa realmente cómo se ve un ciclo while, o si las declaraciones de caso deben sangrarse de cierta manera, entonces está bien. Si decides que los operadores ++ están prohibidos, también está bien. Todo es tu elección.

Tendría que facilitar su búsqueda y actualización, un wiki tal vez o una página web generada automáticamente a partir de una descripción de texto, pero de lo contrario, hágalo. Los estándares tienen una actitud mítica por parte de algunas personas que están más interesadas en seguir fanáticamente el estándar que en escribir un buen código, no sean como ellos: cree su propio estándar que lo ayude donde lo necesite.