Sé que se ha demostrado que un estándar de codificación ayuda enormemente. Sin embargo, hay muchas herramientas e IDE diferentes que se formatearán según el estándar que prefiera el programador. Mientras el código esté ordenado / comentado (y no sea un desorden de espagueti), no veo la necesidad de un estándar de codificación.

¿Hay algún argumento para el desarrollo de un estándar de codificación (no tenemos uno, pero estaba buscando crear uno)?

Sin embargo, hay muchas herramientas e IDE diferentes que se formatearán según el estándar que prefiera el programador.

Buena suerte con eso. Según mi experiencia, hay una pequeña cantidad de herramientas (¡cero!) Que pueden formatear correctamente el código del formato X al formato Y. Hay demasiadas cosas que se interponen en el camino. Tabulaciones frente a espacios, declaraciones de varias líneas, etc. Basta con mirar la implementación de GNU de los archivos de biblioteca estándar de C ++. Lo que puede hacer es hacer que su IDE lo haga es usar siempre espacios en lugar de pestañas y simplemente no molestarse en formatear el código extranjero. Ahora su código se ve como a usted le gusta, y el código externo se ve como el autor original lo escribió.

Un estilo de sangría específico es lo último que debe especificar un estándar de codificación. Eso está a punto de comenzar una guerra religiosa de programación. En mi opinión, un estándar de codificación debe especificar un conjunto razonable de estilos de sangría aceptables, pero dejar los detalles a los autores de un paquete. El estilo de sangría es, o debería ser, una pequeña parte de un estándar de codificación. Regla número cero de estándares de codificación: no se preocupe por las cosas pequeñas. El estilo de sangría es algo pequeño.

Cosas más grandes:

• ¿Cómo nombro las cosas?
• ¿Están ciertas partes del idioma fuera de los límites?
• ¿Es necesario compilar el código limpio y con qué configuración del compilador?
• ¿El código tiene que pasar ciertas métricas?
• ¿Qué tipo de prueba se necesita?
• ¿Qué tipo de documentación se necesita, tanto en el código (comentarios) como en otros lugares?
• Lo más importante, ¿cómo obtengo una exención al estándar?

Anexo
Quizás lo más importante es qué no incluir en los estándares de codificación. Temas como cómo escribir requisitos no pertenecen a los estándares de codificación. Los detalles sobre las pruebas tampoco pertenecen. Un proyecto no debe utilizar los estándares de codificación como sustituto del plan de gestión del proyecto, el plan de gestión de pruebas, el plan de verificación y validación, etc. El objetivo de los estándares de codificación es mejorar la seguridad, calidad, comprensibilidad, mantenibilidad del código, y otras "ilidades". Hay muchas maneras de garantizar que esto no suceda. Solo unos pocos: convertir los estándares en un libro tan complejo como las leyes tributarias de algunos países, incitar a programar guerras religiosas, tener convenciones de mala denominación.

Los estándares de codificación pueden tener consecuencias no deseadas. Ejemplo: algún tonto de un ingeniero de proyecto interpretará que la "regla de no tener números mágicos" significa eso if (index == 0) {...}y for (ii = 0; ii < 3; ++ii) {...}debe cambiarse a if (ZERO == index) {}y for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}No te rías. Lo he visto suceder. Hoy en día, cuando escribo un estándar de codificación, es una "directriz sin números mágicos" en lugar de una regla para contrarrestar este tipo de tonterías.

El estándar de codificación no es la defensa número uno contra el mal estilo de programación / prácticas de codificación peligrosas. La revisión del código es. A pesar de muchos años de automatización, todavía no hay nada mejor que tener un conjunto algo subjetivo de ojos humanos que mire y juzgue un fragmento de código.

Los estándares de codificación no se refieren solo a los parámetros preferidos indent, sino que también incluyen convenciones de nomenclatura, convenciones de comentarios y una gran cantidad de posibles recomendaciones para expresiones idiomáticas, uso de funciones de lenguaje, etc.

Más al punto, todavía necesita documentar todo esto en alguna parte. Y finalmente, no todos querrán usar un IDE que formatee el código de esa manera ...

Si usa un estilo consistente dentro de un equipo, su código se vuelve más fácil de leer. Cuando su código sea más fácil de leer, su equipo será más productivo. Serán más productivos porque no tienen que analizar mentalmente el código y pueden centrarse en la lógica en lugar de la sintaxis al revisar y mantener el código.

Si cada persona deja que el IDE vuelva a formatear el código a su elección, tiene uno de dos problemas: debe asegurarse de volver a convertirlo siempre al formato original al guardarlo o sufrir el hecho de que sus diferencias mostrarán mucho ruido, haciendo que sea más difícil ver qué ha cambiado en la lógica del código.

Respuesta corta: Sí, refleja la calidad .

¿Qué es y por qué lo necesitamos?

Los estándares de codificación son una pieza muy importante de software de alta calidad. Que hacen aumentar la productividad en el proceso de desarrollo, el código de marca más fácil de mantener, y mantener el código de ser atado a una persona o equipo. La consistencia en el estándar de codificación también diferencia el código creado prematuramente del arte bien elaborado.

OK, cada desarrollador sabe que las convenciones de codificación son buenas. ¿Pero de dónde deben venir los estándares?

En su mayoría lo dicta el vendedor que posee el producto. Cada desarrollador puede elegir entre muchos estándares de codificación de la industria. Algunas compañías Microsoft, Oracle y Sun Microsystems ofrecen pautas.

¿Hay algún argumento para el desarrollo de un estándar de codificación (no tenemos uno, pero estaba buscando crear uno)?

Sí, hay estándares de la industria que se recomiendan para su uso. Sin embargo, cada estándar de codificación es específico para la plataforma de desarrollo. Por lo tanto, los estándares de codificación son principalmente específicos del idioma. Por ejemplo, Java tiene un estándar diferente que .NET. Por ejemplo, C # .NET está utilizando esos estándares en esta referencia .

Normas comunes

Los estándares comunes no dependen de ningún lenguaje de programación. Además de los estándares ofrecidos por el proveedor, también conocidos como los estándares de codificación de la industria mencionados, hay diferentes anotaciones de programación como la notación húngara o CamelCase . Creo que los estándares de codificación de Microsoft .NET se basaron inicialmente en notaciones de CamelCase.

Normas y pautas de codificación del equipo

En general, cada equipo de desarrollo debe acordar los estándares de codificación tan pronto como se inicie el proyecto. Las pautas de codificación generalmente son creadas por el jefe de equipo o el arquitecto jefe de la empresa. Por lo general, es un documento abierto que debe seguirse y mejorarse según sea necesario. Por ejemplo, en nuestra empresa tenemos páginas Wiki donde este documento se carga y está disponible para los desarrolladores de la empresa.

Tomaré la opinión controvertida y diré que no, no necesita un estándar de codificación . O las reglas son, como usted dice, pautas exigibles por el IDE, las mejores prácticas generales que todos en cada empresa deben seguir, o son llamadas de juicio caso por caso por equipo que deben ser realizadas por más de una persona en un equipo capaz mediante programación de pares o revisiones de código.

Cosas como ¿Cómo deberíamos nombrar esta variable? ¿Qué características del lenguaje debemos usar? ¿Deberíamos evitarlo? ¿Qué prueba es mejor? Es mejor dejarlas sin respuesta hasta que encontremos el problema definido en el que estamos trabajando en este momento .

Cristalizado a partir de estas decisiones minuciosas, pueden surgir patrones / patrones informales dentro de los equipos, basados ​​en la intersección con el dominio del problema actual y las tecnologías en uso. La codificación de estos significa que creemos que cosas como el estándar de nomenclatura, el subconjunto de lenguaje apropiado, etc. utilizados en estos proyectos, basados ​​en cientos de micro decisiones, y adoptados informalmente por estos equipos deberían guiar cada proyecto en el futuro.

En principio, parece una gran cosa, pero en realidad se convierte en un imán para la política. ¿Qué herramientas podemos obligar a todos a usar? ¿Qué quiero obligar a otras personas a evitar? Si todos estuvieran de acuerdo con estas preguntas, no necesitaríamos un estándar. Solo lo haríamos. En mi experiencia, los estándares surgen del deseo de que un subconjunto de desarrolladores ejerza control sobre otro subconjunto. Típicamente, este tipo de política y la vigilancia tecnológica que la sigue solo sofocan la innovación en lugar de proporcionar orientación.

Si desea una guía real , en lugar de leer un estándar con un montón de reglas inútiles, busque miembros capaces de su equipo y pregúnteles qué piensan. ¿Por qué han sido quemados? ¿Cómo te sugieren que escribas código? Obtendrá una variedad de respuestas útiles con mucha experiencia valiosa para respaldarlo. Verá mucha intersección basada en la experiencia común. En lugar del monocultivo impuesto por el estándar, también verá mucha diversidad que solo puede ayudarlo a ver muchas formas válidas de resolver problemas.

Y cuando alguien le dice que no haga algo debido a una regla en el "estándar" pero no tiene experiencia o respaldo razonable a su reclamo, ignórelo. Aquí el estándar no ha servido a nadie ni ha hecho que nadie sea un mejor desarrollador.

Ahora que los aviones comerciales están volando por cable, es de esperar que los programas que vuelan el avión basados ​​en los aportes de los pilotos funcionen. Cuando los programadores escriben dicho código, usted espera que sigan un conjunto estricto de reglas para evitar errores de programación comúnmente evitables. Una forma de hacerlo es con un estándar de codificación.

Ver: Propuesta de normas de codificación de la Administración Federal de Aviación C y C ++

Necesito decir mas.

Nota: No pude encontrar el estándar real de la FAA en línea, pero lo he visto.

Para mí es una cuestión de disciplina y ser disciplinado siempre ayuda, es un reflejo de la calidad del trabajo que produce.

Dicho esto, haría el estándar de codificación teniendo en cuenta el IDE y / o las herramientas en uso. Además, el IDE debe configurarse de manera idéntica (por ejemplo, el IDE de cada desarrollador debe usar todas las pestañas o todos los espacios en blanco para la sangría y el IDE de todos debe tener la misma longitud de pestaña) para cada desarrollador para que todos puedan seguir el estándar fácilmente ...

Además, se podrían desarrollar y utilizar secuencias de comandos de registro que pueden ayudar a cumplir con los estándares de codificación en cierta medida, por ejemplo, pueden corregir la sangría antes de comprometer realmente el archivo registrado en el sistema de control de versiones.

¡Los estándares de codificación NO podrían ser más importantes! Soy un ávido usuario de CakePHP y me gusta revisar los conjuntos de cambios de versión a versión y los desarrolladores no siguen los estándares allí.

De hecho, estaba tan molesto por las diferencias de estilo que tuve que escribir Un breve discurso sobre las convenciones de codificación . Cuesta mucho tiempo y dinero traer nuevos desarrolladores a un equipo existente, solo imagínense traer un nuevo desarrollador sin estándares ... aprender el código sería lo siguiente imposible.