Manejo de estándares de codificación en el trabajo (no soy el jefe)

Trabajo en un equipo pequeño, alrededor de 10 desarrolladores. No tenemos estándares de codificación en absoluto. Hay ciertas cosas que se han convertido en la norma, pero algunas formas de hacer las cosas son completamente dispares. Mi grande es la sangría. Algunos usan pestañas, otros usan espacios, otros usan un número diferente de espacios, lo que crea un gran problema. A menudo termino con conflictos cuando me fusiono porque alguien usó su IDE para formatear automáticamente y usan un carácter diferente para sangrar que yo. No me importa cuál usemos, solo quiero que todos usemos el mismo.

De lo contrario, abriré un archivo y algunas líneas tienen corchetes en la misma línea que la condición, mientras que otras las tienen en la línea siguiente. De nuevo, no me importa cuál, siempre y cuando sean todos iguales.

Le mencioné el tema de los estándares a mi gerente directo, uno a uno y en reuniones grupales, y él no está demasiado preocupado por eso (hay varios otros que comparten la misma opinión que yo). Saqué a relucir mi preocupación específica sobre los caracteres de sangría y pensó que una mejor solución sería "crear algún tipo de script que pudiera convertir todo eso cuando empujamos / sacamos del repositorio". Sospecho que no quiere cambiar y esta solución parece demasiado complicada y propensa a problemas de mantenimiento en el futuro (también, esto aborda solo una manifestación de un problema mayor).

¿Alguno de ustedes se ha encontrado con una situación similar en el trabajo? Si es así, ¿cómo lo manejaste? ¿Cuáles serían algunos buenos puntos para ayudar a vender a mi jefe según los estándares? ¿Sería una buena idea comenzar un movimiento de base para crear estándares de codificación, entre aquellos de nosotros que estamos interesados? ¿Estoy siendo demasiado particular, debería dejarlo ir?

Gracias por su tiempo a todos.

Nota: ¡ Gracias a todos por los excelentes comentarios hasta ahora! Para ser claros, no quiero dictar un estilo para gobernarlos a todos. Estoy dispuesto a reconocer mi forma preferida de hacer algo a favor de lo que mejor se adapte a todos. Quiero consistencia y quiero que esto sea una democracia. Quiero que sea una decisión grupal en la que todos estén de acuerdo. Es cierto que no todos saldrán con la suya, pero espero que todos sean lo suficientemente maduros como para comprometerse a mejorar el grupo.

Nota 2: Algunas personas están atrapadas en los dos ejemplos que di arriba. Estoy más interesado en el meollo del asunto. Se manifiesta con muchos ejemplos: convenciones de nomenclatura, funciones enormes que deberían dividirse, si algo entra en una utilidad o servicio, si algo es constante o inyectado, si todos usamos diferentes versiones de una dependencia o lo mismo, si un La interfaz se debe utilizar para este caso, cómo se deben configurar las pruebas unitarias, qué se debe probar unitariamente, (específico de Java) si se deben usar anotaciones o configuraciones externas. Podría seguir.

Un compañero de trabajo y yo tuvimos un problema similar en nuestro equipo cuando nos unimos por primera vez (me uní al equipo primero, se unió aproximadamente un año después). No había estándares de código reales. Somos una tienda de MS e incluso no se utilizaron los estándares de codificación de MS. Decidimos liderar con el ejemplo. Nos sentamos juntos y redactamos un documento que tenía todos nuestros estándares: estándares IDE, estándares de nombres, todo lo que se nos ocurría. Luego él y yo acordamos seguir el estándar explícitamente. Envié un correo electrónico al equipo (de los dos) y les notifiqué que habíamos encontrado una falta y que íbamos a abordar la falta con nuestro documento. Invitamos críticas, ideas, comentarios, opiniones. Recibimos muy poco en la forma de retroalimentación y solo un pequeño retroceso. Él y yo inmediatamente comenzamos a usar los estándares, y a medida que incorporamos desarrolladores junior a nuestros proyectos, los presentamos al estándar y comenzaron a usarlo. Tenemos algunas pistas que se mostraron reacias al principio pero que poco a poco comenzaron a usar el estándar para muchas cosas.

Descubrimos que muchos de los desarrolladores junior habían reconocido el mismo problema, pero estaban esperando que alguien más tomara la decisión. Una vez que hubo un plan a seguir, muchos estaban ansiosos por adoptarlo. Las nueces difíciles de descifrar son las que se niegan a codificar por cualquier otro medio, y generalmente se excluirán de la imagen a largo plazo.

Si quieres estándares, abre el camino. Cree una lista sugerida de estándares que cree que beneficiarían a su equipo. Envíelo a sus compañeros y clientes potenciales para recibir comentarios. Estoy seguro de que otras personas en su equipo tienen ideas similares, pero probablemente carecen del sentido común para hacer algo al respecto. Como dijo Gandhi: "Debes ser el cambio que deseas ver en el mundo".

Los estándares no deberían ser algo definido e impuesto por un gerente. El equipo en su conjunto debe estar de acuerdo con los estándares. Si no pueden ponerse de acuerdo sobre un conjunto común de estándares, fracasará el lograr que un gerente los imponga.

Usted y los demás que estén de acuerdo con usted deben predicar con el ejemplo. Comience a usar los mismos estándares de codificación, publíquelos y promovéalos al resto del equipo e invite a comentarios sobre cómo mejorarlos.

Aquí está la parte importante cuando se trata de promover estándares: asegúrese de que el enfoque no esté en encontrar la mejor manera de hacer las cosas, sino en encontrar una manera consistente de hacer las cosas. Por mucho que algunas personas puedan estar en desacuerdo, no hay un estilo de llave verdadero, ningún estilo de comentario verdadero, etc. Lo que hace que el código sea más fácil de leer (y, por lo tanto, más fácil de mantener) es un estilo consistente, sin importar cuál sea.

¿Puede mostrar alguna evidencia del tiempo que ha perdido debido a los problemas que esto está causando?

Si pasa una cantidad significativa de tiempo trabajando en estos problemas, o si está causando errores que tardan en solucionarse, entonces este es un costo que puede reducir drásticamente mediante la adopción de estándares de codificación.

Por lo tanto, mantenga un registro de los problemas que encuentre y el tiempo que lleva resolverlos, tanto para usted como para sus colegas (si los conoce).

Luego, cuando tenga una cantidad razonable de datos, preséntelos a sus colegas. Deberían ver el beneficio de adoptar un estándar. Si no, muestre los datos a su jefe y su jefe. Demuestre que al tener estándares de codificación puede ahorrarle dinero a su empresa y ellos deberían respaldarlo para que los adopte.

En su situación particular, creo que la solución de su jefe es buena. Nadie tiene que cambiar lo que han estado haciendo durante toda su carrera, y eso está bien porque los bits de estilo de código que el compilador ignora no importan mientras el código sea legible. Si todos hicieran un autoformato a su estilo al hacer el check out y un autoformato a un estilo estándar al registrarse, todo estaría bien. (Lamentablemente, sugerí que donde trabajo y me opuse porque el codificador ya no escribiría el mismo código exacto que el servidor de integración continua).

Creo que los estándares de codificación son buenos cuando se aplican a lugares donde hace una diferencia real en la calidad del código: por ejemplo, métodos pequeños, clases que tienen una responsabilidad claramente establecida, comentarios útiles y precisos para los bits más difíciles, etc. Desafortunadamente, esos aspectos son más difíciles de verificar automáticamente, pero eso es fundamental para el desarrollo de software. Todo lo que realmente puede hacer es enseñar a los demás buenas prácticas y aprender a leer el código con la llave en la línea incorrecta.

Con respecto a los estándares de codificación: subiré a bordo con casi todos los demás al decir que los estándares de codificación son "algo bueno" (versus ningún estándar).

Sin embargo, no te dejes llevar. He trabajado en algunos proyectos que dictaron un estilo de sangría específico, hasta el número de caracteres (y cuando los proyectos llegan tan lejos, inevitablemente eligen algo estúpido como una sangría de 8 espacios). No te preocupes por las cosas pequeñas.

Una solución simple: dé a los desarrolladores un conjunto limitado de opciones para llaves y sangría, pero dicte que el estilo y la sangría de las llaves deben ser consistentes en un módulo. (Desea que foo.h y foo.cpp sigan el mismo estilo, ¿no?) Los encargados del mantenimiento deben adaptarse al estilo existente; no pueden reescribir un módulo para adaptarse a su estilo caprichoso. Múltiples estilos dentro de un módulo es simplemente confuso y es un signo de descuido. Cuando veo esas tonterías me hace preguntarme qué más está mal.

También es posible que desee pensar en prohibir las pestañas para la sangría en el contenido guardado de un archivo . La mayoría de los IDE / editores hacen un trabajo razonable traduciendo las pestañas de entrada del usuario a espacios, y la mayoría tiene opciones para hacer que esa traducción sea automática. Muchos hacen un trabajo horrible cuando el archivo ya contiene pestañas, particularmente una bolsa mixta de pestañas y espacios.

Dicho todo esto, creo que puede tener un problema más profundo en su proyecto. Mencionaste problemas con la fusión. Si necesita fusionar mucho, puede ser una señal de una mala partición del proyecto. Así como demasiados cocineros estropean el caldo, demasiados programadores que operan en el mismo archivo estropean el proyecto. ¿Por qué cada uno de Joe, Susie y tú tocan foo.cpp?

Esta es una de las áreas en las que se realizan algunas investigaciones. Básicamente, la pregunta principal es si estás haciendo revisiones de código. Las revisiones de código son sin duda el medio más eficiente para mejorar la calidad del código. (Fuente: Instituto de Ingeniería de Software, CMU). Ciertamente es más eficiente que un probador adicional.

Ahora, las revisiones de código se benefician de un estándar de codificación común, ya que eso hace que sea más fácil leer el código de otras personas. Eso le proporciona un argumento de dos pasos para introducir estándares de codificación: al final, hace que sea más barato producir un buen código.

Como ya hay "varios otros" que están con usted en esto, sugeriría una reunión improvisada. Invite a todos los desarrolladores, tómese un momento y descubra qué cosas le molestan a usted y a sus colegas día a día. No intente encontrar soluciones específicas al principio, solo descubra qué necesita cambiar en la forma en que todos escriben código en la actualidad.

Luego, vea si todos pueden ponerse de acuerdo sobre algunos conceptos básicos. La sugerencia de usar el mismo estilo dentro de cada módulo que @David Hammen mencionó es un buen comienzo, y creo que la mayoría de los desarrolladores podrían aceptarlo.

Si, una vez que tiene ese inconveniente, siente que todos pueden ponerse de acuerdo sobre un estilo básico para escribir un código nuevo, esa es una buena adición. Concéntrese en cosas que realmente impactan la mantenibilidad; los problemas de nomenclatura estarían en lo más alto de mi lista personal porque si tiene media docena de estilos de nomenclatura diferentes en un solo producto de cualquier complejidad notable, se convertirá en un dolor de cabeza muy rápido, pero nuevamente, concéntrese en lo que usted y su equipo consideran importante . Redacta un documento corto que todos puedan aceptar al menos seguir (incluso si tienen un estilo de mascota diferente) y envíalo por correo a todos en el equipo. Conviértalo en un documento "vivo", asegúrese de actualizarlo con el tiempo, pero asegúrese de no hacerlo demasiado rígido y específico.

A menos que su jefe participe en la redacción del código, no debe preocuparse demasiado por el estilo exacto que se adopte (siempre que se centre en la legibilidad y la facilidad de mantenimiento), pero debería poder ver los beneficios de todos los miembros del equipo siguiendo un estilo común Al escribir el código.

Hay algunas cosas que son dolorosas. Lo más doloroso es un IDE que reformatea automáticamente el código, combinado con desarrolladores que configuran sus IDE de diferentes maneras. Cada vez que compara el código, tiene cientos de cambios después de que alguien con diferentes configuraciones edita el código. Eso es inaceptable Aquí debe juntar las cabezas de todos, acordar un conjunto de configuraciones y rechazar cualquier registro por parte de cualquiera que use diferentes configuraciones. Si cambio una sola línea de código, los diferenciales deberían mostrar una sola línea de código modificada, y no cientos.

Todo lo demás es inofensivo o hay mejores maneras de hacer cosas de las que otros pueden estar convencidos. Aquí la regla debería ser: no te metas con el código de otras personas a menos que realmente lo mejoras. Y una combinación de estilo A y estilo B siempre es peor que tanto el estilo A como el estilo B.

Asegúrese de seguir las mejores prácticas. Que es diferente por idioma. Pero allí no necesita estándares (que pueden haber sido escritos por alguien bien intencionado pero no tan bien informado), pero todos deberían tratar de dar buenos ejemplos.

Definitivamente evite las luchas de poder. No hay nada peor que un pequeño Hitler en su equipo tratando de obligar a todos a su voluntad. Y ese es desafortunadamente el tipo que se ofrecerá como voluntario para escribir sus estándares de codificación :-(

Todos los ejemplos que ha dado son básicamente sobre espacios en blanco y formato. Si ese es el mayor problema, estoy de acuerdo con su gerente: no es un gran problema.

Donde los estándares son realmente muy útiles es nombrar cosas y reducir la complejidad. Cómo nombrar identificadores, clases, dónde colocarlos, etc. Mantener los nombres consistentes es extremadamente importante, especialmente en un proyecto grande. Las reglas para reducir la complejidad incluyen mantener las funciones bajo un cierto número de líneas (dividirlas en funciones más pequeñas) o mantener las listas de parámetros debajo de un cierto número de argumentos (tal vez debería agruparlos en un objeto y pasarlos).

Si un desarrollador específico en su equipo escribe código que es más difícil de entender / depurar porque incluye muchos fragmentos largos de código con nombres de variables de una sola letra, esa es una buena razón para adoptar algunos estándares, y no algo que se pueda arreglar con un guión. Es algo bueno señalar (con tacto) como algo que los estándares pueden mejorar.

Otra razón por la que su gerente puede no verlo como un problema es que en realidad no leen el código de los demás muy a menudo. Eso puede suceder cuando todos tienen su propia área del código y no se aventuran demasiado fuera de ella. Eso funciona bastante bien hasta que alguien deja la organización, lo que podría suceder por una variedad de razones buenas o malas. Los estándares que ayudan a la legibilidad facilitarán que un nuevo desarrollador se haga cargo del mantenimiento de un código.

entra en conflicto cuando fusiono porque alguien usó su IDE para formatear automáticamente y usa un carácter diferente para sangrar que yo

Parece que este es tu problema, no el formateo, sino el formateo. Este es un gran problema para los SCM y el consejo es simple: no lo hagas. Entonces, la próxima vez que alguien vuelva a formatear todos los espacios a pestañas, o refactorice los corchetes a su estilo preferido, debe abofetearlos. Haz que hagan la fusión en su lugar; párate sobre ellos con la mirada de desaprobación de la pérdida de tiempo que ha causado su desconsideración.

La alternativa es poner un formateador previo a la confirmación, que siempre formatea todo el código al estilo estándar antes del registro. Si tiene un equipo de desarrolladores que vuelven a formatear de forma habitual, esta es una buena opción: el SCM siempre verá el mismo formato, por lo que los deltas serán pequeños y agradables de combinar.

Cuando alguien sugiere un nuevo estándar de codificación donde trabajo, votamos sobre él. Si obtiene un voto mayoritario, se acepta; de lo contrario, se rechaza. Si no hace esto, no obtendrá la aceptación de sus estándares y no se utilizarán incluso si están documentados.

A partir de su problema específico, su mejor apuesta probablemente comenzará con la sugerencia de Joel y liderará con el ejemplo. Reúna a 1 o 2 programadores que se preocupen por esto, llegue a un acuerdo y tendrá algo de fuerza que imponer sobre los perezosos.

Ahora, para el problema genérico, me parece mejor simplemente modular . Cada persona obtiene un archivo diferente, si tiene que dar mantenimiento a un archivo, mantiene intactos sus estándares de codificación, incluso si es diferente del otro. ¿Necesita escribir en el mismo archivo? Cree un archivo de subconjunto e inclúyalo en su lugar.

¡No intentes esto!

Liderar por contraejemplo. Intenta hacer que el formato de tu código sea lo más horrible posible y comprueba muchos cambios horriblemente formateados en el bonito código de otras personas. Cuando ocurre la reacción (inevitable), diga que lo que está haciendo está bien porque no hay un estándar de codificación.

Si sus compañeros de trabajo no lo linchan (!!), puede terminar con un estándar de codificación.

Obviamente, esta es una estrategia de alto riesgo ... :-)