¿Tratar con compañeros de trabajo que no tienen un estilo de codificación consistente?

¿Qué haces cuando trabajas con alguien que tiende a escribir código estilísticamente malo? El código del que hablo suele ser técnicamente correcto, razonablemente estructurado e incluso puede ser algorítmicamente elegante, pero parece feo . Tenemos:

• Mezcla de diferentes convenciones de nombres y títulos ( underscore_styley camelCase, y UpperCamel, y CAPStodo ello se aplica más o menos al azar a diferentes variables en la misma función)
• Espaciado extraño e inconsistente, p. Ej. Functioncall (arg1 ,arg2,arg3 );
• Muchas palabras mal escritas en comentarios y nombres de variables

Tenemos un buen sistema de revisión de código en el que trabajo, por lo que podemos revisar y solucionar lo peor. Sin embargo, parece realmente insignificante enviar una revisión de código que consta de 50 líneas de "Agregar un espacio aquí. Deletrear 'itarator' correctamente. Cambiar esta capitalización, etc."

¿Cómo animarías a esta persona a ser más cuidadosa y consistente con este tipo de detalles?

Acordar una convención de codificación

Incluso si este es un buscapersonas. Sugiero que todo el equipo se siente y todos estén de acuerdo en la convención básica de codificación de trabajo que todo el equipo puede usar.

Creo que solo tienes que seguir haciendo lo que estás haciendo. Tenga un conjunto claro de pautas de codificación y aplíquelas durante las revisiones de código. Si un desarrollador obtiene 50 o 100 líneas de "Agregar un espacio aquí" y "Deletrear 'iterador' correctamente" cada vez que intenta registrar algo, y en realidad no se le permite registrarse antes de que todo se arregle, eventualmente Tendré que comenzar a escribir código más limpio solo para evitar la molestia.

Creo que si arreglas estas cosas tú mismo, como sugirió NimChimpsky, estarás limpiando a esta persona para siempre.

Llamo a BS a todos los que dijeron que los errores de ortografía y el formato de nombres de variables no importan. Obviamente, solo han leído su propio código. Y observe esa palabra allí mismo: lea. Imagínese leer un libro con muchos errores ortográficos, formateo confuso, interlineado incoherente y otros tipos de pereza que prevalecen en una gran cantidad de código fuente. Sería tedioso.

Para una profesión donde su sintaxis debe ser 100% correcta para funcionar, simplemente no hay excusa para que un desarrollador real no tenga un estilo de código limpio y consistente. Cualquier otra cosa es descuido y pereza. Siempre cuestiono la corrección del código con formato descuidado en la implementación.

Tenemos un buen sistema de revisión de código en el que trabajo, por lo que podemos revisar y solucionar lo peor. Sin embargo, parece realmente insignificante enviar una revisión de código que consta de 50 líneas de "Agregar un espacio aquí. Deletrear 'itarator' correctamente. Cambiar esta capitalización, etc."

Lo cambiaría yo mismo y luego agregaría un comentario cortés en el código.

Esto supone que ya hay una guía de estilo como la pregunta:

Tenemos un buen sistema de revisión de código.

Así que mi sugerencia es el último recurso, creo que es tan rápido cambiarlo usted mismo y dejar un comentario, como enviar un correo electrónico o lo que sea.

Creo que las convenciones como el nombramiento de clases y variables son importantes y deben seguirse a través de un código elegante y eficiente también, pero a riesgo de que mi respuesta sea rechazada muchas veces, debo decir que, en general, el paradigma del "código bonito" se empuja mucho en mi humilde opinión en mi humilde opinión muy sobrevalorado.

En primer lugar, el desarrollador que lo escribió tendrá que mantenerlo en primer lugar, y si alguna vez lo atropella un autobús y otro programador no puede entender cómo funciona porque el código no es "bonito", diría que el otro desarrollador no es muy bueno de todos modos. Y hay muchos formateadores / embellecedores automáticos, por lo que cualquiera puede usarlos para embellecer el código si es necesario, sin perder tiempo mientras está "en el flujo" / "en la zona".

Tenga en cuenta que no estoy abogando por la codificación de estilo spaghetti / cowboy aquí, de hecho, he visto un código de spaghetti muy bien formateado (cuerpos de funciones que abarcan 4-5 pantallas, variables globales dispersas en diferentes archivos de código fuente, generalmente malas selecciones de nombres , etc.)

Uno de mis colegas escribe html de tal manera que hace que mi piel se erice. Imagina mi html agradable y estructurado con dos sangrías espaciales, cortadas en pedazos por etiquetas agregadas al final del mío que terminan en la misma línea o en la siguiente como un borracho que necesita abrazarlo para mantenerse de pie. Las líneas nuevas rara vez tienen sangría, pero si lo están, estoy seguro de que hay un agujero negro altamente caótico en alguna parte de la galaxia que escupe valores de temperatura irracionales de tal manera que sus dígitos reflejan el número de espacios o pestañas utilizados en esa sangría por esta mujer Si tengo suerte, veré una etiqueta de entrada que está cerrada con " </input>". Pesadilla total que puedes entender.

Nadie parece entender esto tampoco, ver cómo para la mayoría de los altos mandos aquí, el código organizado o el código no organizado para ellos es como la diferencia entre nosotros si ponemos queso suizo o queso americano en nuestros sándwiches, es decir, realmente no les importa. Comencé a dejarlo pasar porque estaba estresada con otro proyecto, y creo que ella comenzó a darse cuenta de lo difícil que era comprender un código así antes de querer mejorar. Mi consejo sería demostrar por qué es preferible diseñar su código más que simplemente decirles que lo hagan.

El código del que hablo suele ser técnicamente correcto, razonablemente estructurado e incluso puede ser algorítmicamente elegante ...

Sé feliz de que hayas conseguido todo eso. La mayoría de los programadores quizás te den lo primero en esa lista. Creo que el nombre y el espaciado variable es lo menos importante de qué preocuparse.

Parece que necesita configurar y aceptar una convención de estilo. Si no lo hace, tendrá bibliotecas que tienen 3 sangrías de espacio, otras que tienen 4, algunas que usan Camel Case y otras que usan underscore_case.

¿Son los cambios que desea hacer sus preferencias personales o tiene un estándar real a seguir? Si no tiene un estándar real, no lo haga. Primero establece un estándar. Luego puede obtener software que se puede configurar para refactorizar el código a la configuración estándar (al menos de algunas cosas).

Si tiene un estándar, comience a aplicarlo en la revisión de código. No tiene sentido tener un estándar si no lo aplica en la revisión de código. Esto significará mucho trabajo adicional en el mantenimiento, ya que las personas tendrán que arreglar el código antiguo que no cumplió con el estándar original cuando lo tocan.

Incluso sin un estándar, insista en corregir errores ortográficos en nombres de variables (no me preocuparía especialmente por los comentarios), ya que volverán locos a todos los que toquen el código para siempre.

Los estándares de codificación deben identificarse para que todos sepan lo que son y luego deben hacerse cumplir. Debería haber consecuencias por no seguir las reglas.

Estas son las cosas que deberían proporcionar algún incentivo:

1. Las revisiones de código serán tediosas y más largas de lo necesario.
2. El código será rechazado más a menudo.
3. No se cumplirán los horarios.

Si esta persona no tiene que preocuparse por esto porque nadie hace cumplir sus reglas o no le importa si son improductivas (y nadie hace nada al respecto), no hay mucho que pueda hacer al respecto.

Estaría tentado a sugerir tener un chat privado y ver si ambos pueden encontrar una causa raíz:

1. ¿El compañero de trabajo tiene prisa y porque alguien quería el código ayer, la persona está tratando de hacer que algo funcione tan rápido como pueda? Esta puede ser una oportunidad para informar a esta persona que se centre más en la calidad que en la velocidad en su trabajo. Un mantra como "Tómate tu tiempo" podría ser útil si esto no es contraproducente.

2. ¿Cómo ve la persona su trabajo? Si hay una sensación de orgullo, es posible que tenga un ángulo para obtener una para mejorar. Si es solo un trabajo que paga las cuentas, puede ser mucho más difícil obtener cambios. ¿Saben que no están haciendo un gran trabajo pero están tan cerca de él?

3. ¿Esta persona no está de acuerdo con las convenciones y está tratando de codificar en protesta? Si es así, entonces puede tener un gran problema, pero vale la pena averiguar si este es el caso o si la persona es simplemente perezosa. Qué tipos de motivación pueden ser útiles aquí, por ejemplo, ¿podría apelar a la codicia, el orgullo o algún otro vicio para que la persona mejore? Esto es astuto pero posiblemente efectivo si intentar la ruta del buen tipo no lo lleva a ninguna parte.

4. Cómo ganar amigos e influir La gente tiene algunas sugerencias en términos de ser persuasivo que pueden funcionar, como alabar las mejoras y darle a la persona una buena reputación para defender.

En cuanto a por qué esto debe hacerse en privado, aquí hay algunas razones:

1. Hay una buena posibilidad de humillación, crítica u otras cosas desagradables que es mejor mantener detrás de una puerta que dejar a la intemperie donde alguien puede sentir que su personaje está siendo asesinado.

2. Desea alentar a esta otra persona a abrirse un poco. Un desafío aquí es que algunas personas están tan protegidas que puede llevar mucho tiempo derribar sus muros.

3. Si es posible, sugeriría intentar hacer esto un poco lejos de la oficina. Salga a almorzar, salga a caminar o haga algo para que los alrededores se alteren lo suficiente como para que la persona se sienta un poco más cómoda. Esto puede ser un desafío y requiere conocer a la persona, pero la idea aquí es que en la oficina algunas personas usarán una máscara de trabajo que probablemente no sea útil aquí.

4. Prepárese para que la conversación se caliente o se vuelva fea, pero esto podría ser una buena señal si puede mantener a la otra persona comprometida y tener un buen diálogo. A algunas personas les gusta mantener las cosas al descubierto y otras prefieren formas más sutiles de hacer las cosas. La clave es asegurarse de que está escuchando a la otra persona lo suficiente como para empatizar y tratar de entender su lado.

Tenemos una prueba JUnit que busca problemas de formato. Se ejecuta como parte de la compilación. Continuamente me pica al omitir un espacio entre if, while o for y el paréntesis de apertura. Sin embargo, nuestro código tiene un formato constante.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

El embellecimiento de código como unscrutify podrá resolver algunos de sus problemas. Si está listo para pagar por esto, entonces hay softwares de alto nivel que incorporan las reglas en el código fuente como Parasoft . Parasoft hace obligatorio escribir el código en estilo uniforme. También puedes incorporar tus propias reglas. Cuando se usan tales herramientas, los desarrolladores se ven obligados a usar un estilo uniforme. Y después de un tiempo se acostumbrarán.

Si usa Eclipse, habilite Guardar acciones para los editores de Java y pídales a todos que lo usen. Esto soluciona problemas de formato en cada guardado, pero no soluciona las mayúsculas. ¡Sin embargo, podría ser bastante útil!

¿Qué tan difícil es seguir las convenciones de estilo? Entiendo los errores de ortografía, pero el resto es un indicador de pensamiento descuidado y codificación. Dígale a la persona que necesita ser más consistente cuando se trata de código de producción porque no son los únicos que lo verán. Es simplemente grosero, egoísta y desconsiderado escribir código de producción en un estilo inconsistente.

Jajaja Absolutamente odiarías mi código. No puedo deletrear para salvar mi vida y no me importa.

Pero sé que algunas personas realmente se preocupan por esas cosas.

Le sugiero que despida a la persona que escribe ese código feo si no cambia, busque a alguien que haga las cosas realmente bonitas y espere que pueda escribir código que

suele ser técnicamente correcto, razonablemente estructurado e incluso puede ser algorítmicamente elegante

y si no pueden, al menos puedes mostrar el bonito código roto al cliente y venderlo en eso.

Pero en serio. Concéntrese primero en las cosas realmente importantes. Si no puede encontrar una razón buena y sólida fuera de "me duele mi delicada sensibilidad", ignórela por ahora. Si es realmente importante, siéntese con la persona y convéncela de esa importancia. Cosas como estándares que facilitan la diferencia entre el nivel de clase, el nivel de método, las variables compartidas y constantes hacen la diferencia. Si el codificador en cuestión se preocupa por su profesión, entenderá y tratará de hacer lo correcto.

Mi solución al tratar con recursos subcontratados que no dieron un &% $ # sobre el formateo (o errores fácilmente evitables) fue hacer que el servidor de compilación aplicara esto. Creé un trabajo de servidor CI que se ejecutaba todas las noches y que revisaba el código, ejecutaba Jalopy y findbugs y luego volvía a ingresar el código. Una vez que el otro equipo aprendió que no usar las convenciones de código estándar haría su trabajo más difícil, comenzaron a usar su IDE para mantener un formato estándar.