¿Qué importancia tienen las pautas de formato de código? [cerrado]

Los estándares de codificación son comunes en cualquier organización de desarrollo de software, pero ¿qué importancia tienen que seguir? Puedo entender la necesidad de cierta coherencia, pero cuando se trata de cosas simples como la posición de las llaves, la longitud de la línea, etc., no estoy seguro de que los estándares excesivamente estrictos contribuyan mucho al desarrollo de software.

¿No es más importante que su código sea legible, no que se ajuste a un estándar predefinido? Parece que son más como ... pautas de todos modos.

Pedir a todos que se adhieran al 100% a la misma directriz de formato de código estándar es como pedirles a todos que colaboren por separado para escribir un documento de 100 páginas con el mismo estilo de escritura.

Esperemos que todos escriban el artículo en inglés (o en el mismo idioma), pero serán evidentes diferentes estilos. Algunos lo escribirán bien, otros no. Algunos usarán contracciones, otros deletrearán las palabras completamente (ejemplo: es muy cierto). Etc.

Creo que tocaste los puntos más importantes:

1. Es una directriz
2. Legibilidad

Si desea que el código se adhiera al mismo formato, como un papel con el mismo estilo de escritura, deberá editarlo y revisarlo. El código deberá ser limpiado, revisado, refactorizado, etc.

Nunca he estado en una tienda donde estaba completamente satisfecho con el estilo o el formato de codificación de otro desarrollador (como mínimo porque no es exactamente como el mío). Pero estaré contento si puedo leerlo / entenderlo y si es consistente. Todo lo demás es el azúcar en el azúcar sintáctico.

Entonces, para responder a su pregunta: algo importante, pero ciertamente no es el fin del mundo si no lo hacen.

Para los estándares de formato, sigo lo que hacen los demás. Si están usando PascalCase para todo, entonces uso PascalCase. Si usan _camelCase, entonces yo uso _camelCase. ¿Por qué? Porque limita la cantidad de reformateo que hago, y limita lo que otros tienen que hacer para que "se vea bien". Los estándares de formato generalmente están ahí para facilitar las cosas a todos.

En mi trabajo actual, una de mis primeras tareas fue crear un estándar de codificación para nuestro grupo de desarrollo.

Mi primer esfuerzo fue de unas sesenta páginas (incorporó gran parte de las Pautas del Marco de Microsoft). Me pidieron que lo redujera, y mi siguiente esfuerzo fue de diez páginas, utilizando ideas de una variedad de buenas fuentes. Me pidieron que lo redujera nuevamente, y finalmente lo reduje a tres o cuatro páginas, creo.

Nunca fue adoptado.

¿Por qué? Porque trabajo con muchas personas realmente inteligentes, que ya siguen instintivamente un estándar de codificación sensible.

Por mi parte, sigo las pautas generalmente aceptadas de Microsoft y emulo los estilos de uso común de otros (Javascript y jQuery están formateados de manera diferente a C #, a pesar de que ambos son lenguajes de llaves). También rompo las reglas de vez en cuando, al hacerlo, el código será más legible.

Si usa un IDE que hace lo básico por usted (Visual Studio, por ejemplo), deje que el IDE haga lo suyo y lo que parezca aún difícil de ver, modifique siempre que deje que el IDE haga lo suyo o la siguiente persona que lo formatee automáticamente lo matará de todos modos.

Lo que es más legible para una persona no será para todas las personas.

Si no está utilizando este tipo de IDE, obtenga uno. Incluso pensar en esto durante más de 10 minutos es un desperdicio de recursos en mi humilde opinión.

Creo que hay un beneficio no mencionado en ayudar a comprender rápidamente el código. Cuanto más similar sea el formato del código en un proyecto y en todos los desarrolladores, más fácil (y más inconscientemente) podrá trabajar con el código.

He tenido desarrolladores junior que vienen a mí después de tratar de lidiar con errores incluso simples durante un período prolongado de tiempo. Después de tomarse unos minutos para aplicar nuestro formato de código con ellos, pudieron ver rápidamente el error que se habían perdido antes.

Si bien la legibilidad es definitivamente importante. Si sus estándares de formato de código están bien pensados ​​y se usan correctamente, es posible que pueda ir más allá de solo poder leer el código y poder comprender el código aún más rápido.

Un conjunto de pautas que uso al desarrollar o actualizar nuestros formatos de codificación son los Principios de Agrupación de Gestalt: http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

Como resultado directo / ejemplo, nuestro formato de código requiere que cualquier código de bloque (if, switch, etc.) tenga la llave abierta en la siguiente línea, de modo que se alinee con la llave de cierre:

if(true)
{
}

Con el razonamiento de que, según el Principio de simetría, su mente verá las llaves abiertas y cerradas y más rápidamente podrá percibir el bloque de código de forma natural.

No importa qué idioma o herramienta use, invente algo. Configure su IDE y verifique el archivo de configuración.

Cuando alguien revisa el proyecto, usará los mismos estilos de formato. No importa cuál sea el estilo, solo que sea consistente. Tengo mis propias preferencias con respecto a los espacios v. Pestañas, y en qué línea continúan las llaves. Pero más que mis propias preferencias, solo me importa que un archivo de código fuente determinado esté de acuerdo consigo mismo. Lo hace mucho más legible de lo que es una mezcla resultante de una guerra de formatos.

Lo peor que he encontrado hasta ahora es no usar estándares de codificación. Y tiene prohibido hacer que algún bloque de código sea más legible porque rompe las herramientas diff ... Porque estamos usando parches para aplicar cambios (solicitud de cambio / corrección de errores -> arreglo / cambio -> parche -> parche aplicado por persona "confiable" -> commit) puede obtener un código fuente bastante divertido (desde el punto de vista de la legibilidad). Al menos no tenemos a nadie que use variables de dos letras (-.

[despotricar] Lo más divertido es que todos están de acuerdo en que necesitamos cambiar esto. Incluso hubo un par de intentos de reformateo (automatizado en el commit), pero debido a que falta una sola opción de formato pequeño y diminuto, todo se acabó. Vista ... [/ rant]

Las pautas ayudan a mejorar la calidad del código:

• desde el punto de vista del escritor: muchas reglas apuntan a reducir la introducción de errores. Por ejemplo, una regla que indica que if()o for(;;)construcciones deben ir seguidas de un bloque y no una sola instrucción, hace que la intención inicial del codificador explícita y ayuda a mantener próximos codificadores esto.

• desde el punto de vista del lector: el código que sigue las pautas acordadas se revisa de manera más eficiente que el código con varios estilos. El revisor sabe mejor con menos esfuerzo dónde buscar posibles errores.

No existe un estándar universal para lo que un equipo debe o no debe hacer. Algunos equipos deben seguir pautas estrictas, otros no.

El punto es que deben trabajar juntos como un equipo y decidir qué es lo mejor para su equipo . El código debe ser fácil de leer, porque se lee órdenes de magnitud más veces de lo que se escribe. Si su equipo necesita orientación para crear código legible, cumpla con un estándar de codificación. Si no lo haces, no lo hagas.

Dicho todo esto, creo que la mayoría de los equipos se beneficiarían al acordar una forma estándar de nombrar variables, funciones y clases, posicionar llaves, etc. Si el equipo no puede ponerse de acuerdo en algo tan simple como eso, ¿cómo pueden esperar unirse y tomar las decisiones realmente importantes? Además, su equipo no estará compuesto por las mismas personas para siempre: la gente se va, se contrata gente nueva. Cuanto más fácil sea para las personas nuevas asimilar la base de código, más rápido podrán contribuir al equipo sin disminuir la calidad del código.