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

30

¿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?

JSB ձոգչ
fuente
2
Ayuda de "Impresoras bonitas". Además, ¿su empresa tiene una guía de estilo?
chrisaycock
1
¿Qué pasa con los compañeros de trabajo que no tienen gramática? ;)
Muad'Dib
44
@JSBangs: instale un comprobador de estilo previo a la confirmación y haga que rechace las confirmaciones. Eso los hará formatear correctamente rápidamente. O haga que el gancho previo a la confirmación ejecute un formateador por usted. Algunas cosas se verán pero es mejor que raro es mejor que "horrible", supongo.
haylem
3
Un pensamiento más: puede parecer insignificante, pero es insignificante para un propósito (suponiendo que a) hay un estándar de codificación y que b) todos los demás están de acuerdo y se adhieren a él)
Murph
3
¿Cuál es el historial de este programador? Parece que ha trabajado para muchas compañías diferentes con demasiadas convenciones de formato de código diferentes, y su cerebro las ha internalizado en un desorden desordenado. :-)
Carson63000

Respuestas:

19

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.

Noche oscura
fuente
1
Absolutamente, entonces a) todos están tratando de alcanzar el mismo estándar y saben lo que es yb) su rechazo en la revisión del código puede reducirse a "no cumple con los estándares de codificación" (al menos si el archivo en su conjunto es un lío - ​​si es solo una o dos cosas, necesitarás ser específico)
Murph
Por lo general, nunca he visto a un equipo lograr "acordar" en una hora una convención de codificación completa para cualquier idioma :) Pero si por acuerdo quieres decir "discutir hasta el desacuerdo, y luego imponer por rango y autoridad", entonces eso trabajos. Tienes que poner un pie en algunos puntos porque no encontrarás consenso, o tienes mucha suerte con tu equipo.
haylem
28

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.

Dima
fuente
5

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.

Código difícil
fuente
4

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.

NimChimpsky
fuente
10
Eso envejece bastante rápido.
Robert Harvey
3
Probablemente sea más rápido para usted que enviar un correo electrónico, y en general más rápido para que se solucione el problema, pero es más lento que si el problema no ocurre en primer lugar.
haylem
4

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.)

Jas
fuente
¿Qué dices sobre un código como este? Stackoverflow.com/questions/6221098/save-mapview-as-a-bitmap/… ¿Todavía crees que el programador que se ha ocupado de este "estilo" es un mal programador si él tiene serios problemas con eso?
WarrenFaith
@WarrenFaith, es posible que desee volver a visitar mi tercer párrafo, en particular este artículo aquí: "Tenga en cuenta que no estoy abogando por la codificación de spaghetti / cowboy aquí ...".
Jas
3

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.

Neil
fuente
3

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.

jjnguy
fuente
3
Los programadores pasan más tiempo leyendo códigos que escribiendo códigos. Si el código es ilegible, el costo de extenderlo o mantenerlo se vuelve enorme. Y si los nombres de las variables son inconsistentes, están mal escritos y no son descriptivos, eso hace que el código sea ilegible.
Dima
@Dima, cierto, pero ese código que funciona y es elegante ya es más fácil de leer que el código que está roto y no es elegante.
jjnguy
1
Mi punto es que debería poder mirar un nombre de variable, o un nombre de clase, o un nombre de función, e inmediatamente saber cómo usarlo sin tener que buscar en toda la base de código. También debe poder escribir el nombre siguiendo las convenciones y hacerlo bien sin tener que buscarlo. Le recomiendo que lea "Código limpio" de Robert C. Martin.
Dima
@Dima, estoy de acuerdo en que las variables deben tener nombres descriptivos. El OP no menciona que los nombres son malos, solo que son inconsistentes.
jjnguy
1
En mi experiencia, cuando los nombres son inconsistentes, también tienden a no ser descriptivos. Pero hay otro problema. Cuando los nombres son inconsistentes, te lleva más tiempo recordar cuáles son, y tienes que pasar tiempo buscándolos. Un buen IDE puede ayudar un poco, pero no solucionaría el problema por completo. La programación ya pone suficiente carga en su cerebro, por lo que desea reducir la cantidad de mapeo mental y verificación doble tanto como sea posible.
Dima
2

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.

Wheaties
fuente
2

¿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.

HLGEM
fuente
2

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.

JeffO
fuente
2

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.

JB King
fuente
2

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

Kevin Peterson
fuente
1

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.

Manoj R
fuente
1

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!

texto alternativo


fuente
1

¿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.

davidk01
fuente
0

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.

ElGringoGrande
fuente
55
Si los nombres de sus variables están mal escritos, el siguiente tipo que use su código tendrá que pasar más tiempo arreglando los errores del compilador cuando los deletree correctamente. No se trata de "sensibilidades delicadas". Estas cosas aparentemente triviales causan errores, lo que causa frustración, lo que provoca más errores. Todo eso se suma a los enormes costos de mantenimiento del código.
Dima
44
Es un poco más que sobre "sensibilidad delicada", pero productividad No me importa que alguien con estilos de codificación ligeramente diferentes, que ocasionalmente olvide un espacio, etc. No somos perfectos. Pero cuando parece que todo el archivo ha sido escrito por un estudiante universitario, con un espaciado de línea inconsistente, posiciones, sangría y flujo de código general, simplemente presiono el botón "rechazar" (o revertir) muy rápidamente.
haylem
2
Muchos proyectos exitosos de código abierto (Linux incluido) hacen esto: si no tiene el estilo correcto (y las pruebas unitarias), entonces es rechazado. Lástima si fue bueno y resolvió un problema real: no siempre se puede arreglar el código de otras personas. En general, pierdes menos tiempo y dinero simplemente pasando la pieza ocasional de genio que pasa pero que parece un infierno o es imposible de mantener.
haylem
1
Cosas graciosas. Pero, por supuesto, el punto principal parece perderse. Primero tienes al tipo a bordo con las cosas obvias para las que puedes hacer un caso realmente fuerte. Entonces trabajas en las cosas menos importantes. Hay formas de trabajar con personas fuera de simplemente ahogarlas con reglas. Y tal vez, solo tal vez, la multitud de OCD podría comprometerse un poco o aprender por qué hay tanta variación en el código de los demás. En realidad, podría haber una causa o razón.
ElGringoGrande
0

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.

sal
fuente