¿Qué pasa con todas esas reglas de codificación?

Siempre apoyé la idea de tener reglas de codificación para desarrolladores en una empresa o un proyecto específico. Especialmente si la empresa tiene un tamaño mayor que 10. Cuanto más grande sea la empresa, mayor será la necesidad. Sé que mucha gente no estará de acuerdo, pero he visto proyectos que no los tienen y el código parece un desastre total.

El verdadero problema que surge de esto es cómo hacer que aquellos con cabeza dura que no les gusta usar corchetes en las declaraciones if, o usar la misma cadena de conexiones en todas partes del código, o lo que sea, para usar las reglas de codificación sin hacer que se opongan ¿la idea?

Involúcrelos en la solución de un problema en lugar de que las reglas de lucha. Personalmente prefiero la idea de "guías de estilo", "estándares de codificación" o algo similar, con la esperanza de que evite la reacción instintiva de "reglas = mala".

Pero incluso si lo hace, tiendo a pensar que las reglas están en su lugar por una razón, y la forma de hacer que las personas obstinadas den la vuelta es hacer que se den cuenta de que, siguiendo las pautas, están ayudando a facilitar el código. Leer para todos.

A veces, la presión de grupo es la mejor solución para esto.

En mi trabajo utilizamos las tres soluciones siguientes:

1) Adopte un verificador de estilo de código como el excelente Checkstyle (para Java) o StyleCop (para C #). Estas son herramientas fácilmente configurables que pueden resaltar automáticamente las desviaciones de estilo / regla de codificación. Les da a todos un tercero neutral para determinar qué es y qué no es aceptable.

2) Adopte una plantilla de código de reformateo de guardado automático (aquí hay un ejemplo usando Eclipse) (y otro para Visual Studio) que formateará automáticamente su código al guardar. Esto es excelente para permitir que alguien codifique como lo desee, pero tiene todo el código formateado de la misma manera en guardar / confirmar. Realmente me gusta este y nuestro código nunca ha sido más consistente.

3) Revisiones de código. Espero que esté haciendo esto de todos modos, pero una cosa que esto debería resaltar es donde las reglas / estilos de codificación están rompiendo la convención.

Además de lo anterior, es importante que todos estén en el mismo barco y hayan acordado los estilos / reglas en los que están trabajando. Deje en claro que no obtendrá un acuerdo de todos sobre todo, pero solicite el compromiso del equipo para mantenerse fiel a lo que el equipo decida. Asegúrese de revisar ocasionalmente los estilos / reglas elegidos para tener en cuenta la experiencia del mundo real al usarlos y la rotación del equipo.

El verdadero problema que surge de esto es cómo hacer que aquellos que sean duros no les guste usar corchetes en las declaraciones if, o usar la misma cadena de conexiones en todas partes del código, o lo que sea,

¿Están siendo "testarudos" al no usar paréntesis o es una solicitud "testaruda"?

Escoge tus batallas. Dudo que este sea uno de los que valga la pena elegir. No me gustaría trabajar en ningún lugar que se esperara cerca de este nivel de detalle en el "primer código de registro". Este es un indicador de bandera roja de que el equipo no entiende la refactorización.

OO 101 : "Refactorizar cuando el producto hace lo que debe hacer". No antes.

Es bastante difícil sentarse en el hombro de cada desarrollador individual en equipos grandes, asegurándose que ponen los apoyos donde se piensa que debe ir - la confianza en mí en eso;).

Si realmente siente que está obstaculizando su desarrollo, necesitará un "guardián". No permita que las personas se registren sin una revisión de código, por ejemplo. Haga que el arquitecto técnico o el líder del equipo revisen el código y lo rechacen hasta que "corrijan" el estilo del código. Sin embargo, pronto se cansarán de esto y se ajustarán a las reglas, posiblemente solo durante el tiempo que estén siendo controlados.

Por supuesto, algunas compañías les quitan los privilegios de check-in completamente a los programadores junior. Cuando finalmente aprenden las reglas de codificación de las empresas, obtienen el privilegio.

Creo que estás hablando de problemas de niveles muy diferentes:

cómo hacer esos duros que no les gusta usar corchetes en las declaraciones if,

Eso es principalmente un problema de estilo / legibilidad, a menos que haya un problema explícito de precedencia del operador. Este último no debería ser muy común y, de todos modos, se puede probar en la unidad, por lo que es fácil de solucionar. El primero puede retroceder fácilmente a una Guerra Santa con poco que ganar, pero graves consecuencias negativas para la moral del equipo. Así que tenga cuidado: solo aplique las reglas probadas y comprobadas, que han sido aceptadas por al menos algunos equipos / comunidades y han demostrado que funcionan.

o use la misma cadena de conexiones en todas partes del código,

Si te refieres a las constantes mágicas, eso es realmente un problema de mantenimiento (más potencialmente de seguridad), y como tal, en mi humilde opinión, cualquier desarrollador experimentado comprenderá y aceptará que es una mala cosa.

o lo que sea, ¿usar las reglas de codificación sin hacer que se opongan a la idea?

No puede obligar a las personas a estar de acuerdo con las reglas de codificación: su única oportunidad es llegar a un entendimiento común y aceptación de los miembros del equipo mediante discusión y (a veces feroz) debate . Debe usar argumentos lógicos y convincentes , que muestren el valor detrás de cada regla y expliquen cómo seguirla pagará las molestias de ajustar hábitos arraigados. Por otro lado, trate de hacer la transición lo más fácil posible , por ejemplo, introduciendo el formato de código automatizado en el check-in, de acuerdo con las reglas aceptadas.

Aún así, a veces solo necesita aceptar que las personas tienen opiniones diferentes , por lo tanto, las reglas de codificación que todos pueden aceptar serán indulgentes en ciertos aspectos. Acepte eso y concéntrese en las áreas donde puede mejorar las cosas con menos esfuerzo.

Involúcrelos en el establecimiento de reglas. Esto generalmente ayuda a alentar a las personas a seguirlos.

Para eso es la revisión de código. Los revisores de código no deberían dejar pasar código que no cumpla con los estándares. Asegúrese de no relajar las reglas para soluciones urgentes. Tener que rehacer algunas veces bajo presión para hacerlo hará que los reacios hagan su trabajo correctamente la primera vez.

¿La misma cadena de conexión en todas partes? La solución a eso es refactorizar hasta que haya eliminado toda la duplicación. Los codificadores de copiar y pegar deben ir a la cárcel del programador. (¡No te rías! Steve Ballmer es el director).

Pero el verdadero problema aquí es su verbo "make" . No puede hacer que los programadores hagan nada, y si lo hace, está desperdiciando su característica más valiosa: el profundo compromiso intelectual que proviene de trabajar en algo que le importa.

La forma en que lo resolvería:

1. Insista en que el equipo tenga un estándar de codificación común. Puede tener 5 líneas de largo, pero todos tienen que estar de acuerdo.
2. Cada vez que note un argumento insista en que lo resuelvan juntos y lo pongan en el estándar de codificación. Si observa que las personas reformatean las cosas de un lado a otro, trátelo como un argumento.
3. Siempre que se acuerde un elemento estándar, vea si hay una herramienta que limpiará todo el código base de una vez.
4. Cada dos meses, revise el estándar de codificación y vea cuáles siguen siendo verdaderas y relevantes. El estándar solo documenta lo que la gente está haciendo. Y no tiene sentido mantener elementos en el estándar que se han vuelto obvios.

La programación es un deporte de equipo, o un trabajo artístico colectivo. Lo que la gente acuerda no importa tanto como lo que acuerdan, y son buenos para llegar a nuevos acuerdos según sea necesario.