Sé que se ha comprobado 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 un lío de espagueti), no veo la necesidad de un estándar de codificación.
¿Existen argumentos para el desarrollo de un estándar de codificación (no tenemos uno, pero estaba pensando en 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 reformatear 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. Simplemente observe la implementación de GNU de los archivos de la biblioteca estándar de C ++. Lo que puedes hacer es hacer que tu IDE haga uso de espacios en lugar de pestañas y no te molestes en reformatear el código extranjero. Ahora su código se ve como le gusta, y el código extranjero se ve tal como lo escribió el autor original.
Un estilo de sangría específico es lo último que debe especificar un estándar de codificación. Eso está al borde de comenzar una guerra religiosa de programación. OMI, 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 sangrado 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 sangrado es una cosa pequeña.
Cosas más grandes:
Addendum
Quizás aún más importante es lo que no poner en los estándares de codificación. Los temas tales como cómo escribir los requisitos no pertenecen a los estándares de codificación. Los detalles sobre las pruebas tampoco pertenecen. Un proyecto no debe usar los estándares de codificación como soporte para el 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, la calidad, la comprensibilidad y el mantenimiento del código. y otras "ilidades". Hay muchas maneras de asegurarse de que esto no suceda. Solo algunos: hacer de las normas un libro tan complejo como las leyes fiscales de algunos países, incitar a programar guerras religiosas, tener malas convenciones de nomenclatura.
Los estándares de codificación pueden tener consecuencias no deseadas. Ejemplo: algún ingeniero de proyectos interpretará que la "regla de no contar con números mágicos" significa que if (index == 0) {...} y for (ii = 0; ii < 3; ++ii) {...} deben cambiarse a if (ZERO == index) {} y for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...} No se ría. Lo he visto suceder. Hoy en día, cuando escribo un estándar de codificación, se trata de una "pauta de no contar con 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 las malas prácticas de codificación / estilo de programación. El código de revisión es. A pesar de muchos años de automatización, todavía no hay nada mejor que tener un conjunto subjetivo de ojos humanos que miren y emitan juicios sobre una parte del código.
Los estándares de codificación no son solo los parámetros preferidos para indent , sino que también incluyen convenciones de nomenclatura, convenciones de comentarios y una gran cantidad de posibles recomendaciones para modismos, uso de funciones de idioma, etc.
Más concretamente, aún debe documentar todo esto en algún lugar. Y finalmente, no todos querrán usar un IDE que reformatee 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 en la sintaxis al revisar y mantener el código.
Si cada persona permite que el IDE vuelva a formatear el código a su elección, tiene uno o dos problemas: debe asegurarse de que siempre lo vuelva a convertir al formato original cuando lo esté guardando, o sufrir por el hecho de que sus diferencias mostrarán mucho de ruido, lo que dificulta ver qué ha cambiado en la lógica del código.
Respuesta corta: Sí, refleja la calidad .
Los estándares de codificación son una pieza muy importante de software de alta calidad. Aumentan la productividad en el proceso de desarrollo, hacen que el código sea más fácil de mantener y evitan que el código esté vinculado a una sola persona o equipo. La coherencia en el estándar de codificación también diferencia el código creado prematuramente del arte bien elaborado.
Bien,todoslosdesarrolladoressabenquelasconvencionesdecodificaciónsonbuenas.Pero¿dedóndedeberíanvenirlasnormas?
Ensumayoríaesdictadoporelproveedorqueposeeelproducto.Cadadesarrolladorpuedeelegirentremuchosestándaresdecodificacióndelaindustria.AlgunascompañíasMicrosoft,OracleySunMicrosystemsofrecenpautas.
¿Existenargumentosparaeldesarrollodeunestándardecodificación(notenemosuno,peroestabapensandoencrearuno)?
Sí,hayestándaresdelaindustriaqueserecomiendanusar.Sinembargo,cadaestándardecodificaciónesespecíficoparalaplataformadedesarrollo.Porlotanto,losestándaresdecodificaciónsonensumayoríaespecíficosdelidioma.Porejemplo,Javatieneunestándardiferentea.NET.Porejemplo,
Los estándares comunes no tienen dependencias en ningún lenguaje de programación. Además de los estándares ofrecidos por el proveedor, también conocidos como estándares de codificación de la industria mencionados, hay diferentes notaciones de programación como Notación Húngara o CamelCase . Creo que los estándares de codificación Microsoft .NET se basaron inicialmente en notaciones de CamelCase.
En su opinión, cada equipo de desarrollo debe acordar los estándares de codificación tan pronto como se inicie el proyecto. Las directrices de codificación suelen ser creadas por Team Lead o Chief Architect de la empresa. Por lo general, es un documento abierto que debe seguirse y mejorarse en función de una necesidad. Por ejemplo, en nuestra empresa tenemos páginas Wiki donde se carga este documento y está disponible para los desarrolladores de la empresa.
Tomaré la opinión controvertida y diré no, no necesitas un estándar de codificación . O bien las reglas son, como usted dice, las pautas aplicables de IDE, las mejores prácticas generales que todos en cada compañía deben seguir, o son llamadas de juicio caso por caso por equipo que debe ser realizada por más de una persona en un equipo capacitado. A través de la 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? ¿Debemos evitar? ¿Qué prueba es mejor? Es mejor dejarlos sin respuesta hasta que encontremos el problema estrechamente definido en el que estamos trabajando en este momento .
Cristalizadas a partir de estas decisiones minuciosas, pueden surgir estándares / patrones informales dentro de los equipos, en función de la intersección con el dominio del problema actual y las tecnologías en uso. Al codificar estos medios, 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 de manera informal por estos equipos deberían guiar cada proyecto en el futuro.
En principio, suena como una gran cosa, pero en realidad solo se convierte en un imán para la política. ¿Qué herramientas podemos obligar a todos a usar? ¿Qué quiero forzar a otras personas a evitar? Si todos estuvieran de acuerdo con estas preguntas, no necesitaríamos un estándar. Simplemente lo haríamos. En mi experiencia, los estándares surgen del deseo de que un subconjunto de desarrolladores ejerza el control sobre otro subconjunto. Por lo general, este tipo de política y la vigilancia tecnológica que lo sigue solo frena la innovación en lugar de proporcionar orientación.
Si desea orientación real , en lugar de leer un estándar con un montón de reglas inútiles, vaya a buscar miembros capaces de su equipo y pregúnteles qué piensan. ¿Qué han sido quemados por? ¿Cómo te sugieren que escribas código? Obtendrá una variedad de respuestas útiles con mucha experiencia valiosa para respaldarlo. Verás muchas intersecciones basadas en experiencias comunes. 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 para su reclamo, ignórelo. Aquí el estándar no ha servido a nadie ni ha hecho a nadie un mejor desarrollador.
Ahora que los aviones comerciales están volando por cable, esperaría que los programas que vuelan el avión basados en la entrada de los pilotos funcionen. Cuando los programadores escriben dicho código, espera que sigan un conjunto estricto de reglas para evitar los errores de programación que normalmente se pueden evitar. Una forma de hacerlo es con un estándar de codificación.
Ver: Estándares de codificación propuestos de la Administración Federal de Aviación C y C ++
Necesito decir más.
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.
Habiendo dicho eso, 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, de modo que todos puedan seguir el estándar fácilmente ...
También, se pueden desarrollar y utilizar scripts de verificación que pueden ayudar a cumplir los estándares de codificación en cierta medida, por ejemplo. pueden corregir la sangría antes de ingresar el archivo ingresado 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 están siguiendo los estándares allí.
De hecho, me molestaron tanto las diferencias de estilo que tuve que escribir A Rant breve sobre las convenciones de codificación . Ya cuesta mucho tiempo y dinero traer nuevos desarrolladores a un equipo ya existente. Imagínese traer un nuevo desarrollador sin estándares ... aprender el código sería demasiado imposible.
Lea otras preguntas en las etiquetas coding-standards ide