¿Debo usar Resharper para ordenar el código de otras personas?

Question

Uso Resharper en el trabajo. Algunos de mis colegas no.

Cuando abro un código que ha sido escrito por alguien que no lo tiene, es inmediatamente obvio por la cantidad de naranja en mi pantalla.

Lo que no estoy seguro es en qué medida debería sentirme libre de arreglar los líos que sin saberlo han dejado. Con la mayor parte de lo que estoy viendo, es descuidado pero inofensivo, y realmente no me saltaría si nunca hubiera usado Resharper.

supongo que veo mis opciones en términos generales como

1) La historia de los cambios en el código fuente es esencial para el mantenimiento. Cambie lo menos posible, o el próximo tipo no tendrá la esperanza de descubrir qué ha cambiado. A quién le importa el código inalcanzable, el uso innecesario de .ToString() etc. de todos modos.

2) Cambie las cosas sin sentido como incluye, corrige los comentarios de la documentación del método y cosas por el estilo. Al chico que lo escribió le gusta que su código se vea así, así que déjalo en un estado en el que no se queje, pero deshazte de la naranja innecesaria

3) Naranja es solo roja pero más clara. F12 luego Alt + Intro hasta que aparezca verde.

4) Olvide la naranja, mire esa función de línea monstruo 700. ¿Qué es este 1997? Es hora de estar ocupado ... y si tiene tiempo, presente a su colega a nuestro buen amigo y mentor, el Sr. Fowler.

Tiendo a revolotear entre las opciones dependiendo de cuánto tiempo tengo, en qué medida ahora soy responsable del código, y qué tan complejo se ve el código (lo que me puede hacer 1 o 4 por lo general).

Parece que una de las 4 opciones debe ser el que me esfuerzo para pesar, pero no tengo ni idea de cuál

Answer 1

"Leave the campsite cleaner than you found it." 

Es el principio boyscout. Si se trata de "su" código y lo mantienen luego de introducir poca limpieza, los cambios no deberían ofenderlos, pero ir demasiado lejos puede parecer descortés o puede que usted se apropie efectivamente del código.

Answer 2

hago un "cambio de formato" registro de entrada antes de cambiar cualquiera de la lógica real, esto forma en que puedes ver lo que ha cambiado

Answer 3

Su equipo debe estar de acuerdo con una norma. Si alguien más usa otra herramienta, puede encontrarse en una guerra de edición involuntaria.

Pero si todos pueden estar de acuerdo, entonces sí. Limpia el código sobre la marcha.

Answer 4

Si las herramientas de desarrollo en su equipo no son las mismas, eventualmente habrá aún más problemas. Sigue el check-in "reformateado" sugerido arriba y estandariza el conjunto de herramientas con tus colegas, ya sea bajando el reafilador o dando a todos la varita mágica de formateo.

Answer 5

Si ya está registrado, tenga cuidado. Algunas personas se ponen terriblemente sensibles y se considera grosero si alguien en su equipo todavía está utilizando herramientas de hace una década que no pueden desactivar la detección del espacio en blanco durante una diferencia.

En general, voy a limpiar el estilo del código para ponerlo en línea con los objetivos de estilo de organización establecidos cuando toco el código por otra razón. Sin embargo, intente recordar que el estilo es estilo y, como tal, no existe "una sola manera verdadera". No hagas enemigos porque no te gusta el hecho de que un colega use menos (o más) espacios en blanco que tú.

Answer 6

La refactorización innecesaria es solo eso - innecesario. Agrupa los registros del historial del repositorio y puede introducir errores.

Si se supone que el material "sin sentido" (documentación, comentarios, etc.) se formatea de cierta manera, y no cumple con sus estándares de desarrollo, entonces lo haría todo de una vez en el menor número de registros posible .

Cuando realmente está trabajando en las piezas de código y tiene la oportunidad de probar sus cambios, haga la refactorización a continuación. Resharper siempre estará disponible para mostrarle el camino en ese punto.

Answer 7

Cada vez que cambie algo, independientemente de la intención, corre el riesgo de romper algo involuntariamente. En el aspecto personal, no cambiaría el código de otra persona sin hablar primero con ellos.

Answer 8

Recomiendo solo cambiar cosas cuando lo necesite. Existe, por supuesto, una definición variable de lo que significa "necesidad". Por ejemplo, si escribe un método que llama a otro método, ¿y este método que está llamando tiene una duplicación de código? Refactorizaría eso, y mientras estoy en eso eliminaría el exceso de declaraciones using, etc. Sin embargo, trataría de evitar solo un refactor masivo de toda la base de código "solo porque".

Answer 9

Mi sugerencia sería que si usted hace un cambio de formato que se haga por separado de las modificaciones de código. La razón de esto es que puede marcarlo como "reformatear solamente" en el repositorio y un cambio de código legítimo no será ocultado en medio de un grupo de cambios de espaciado, lo que hace imposible que usted o el siguiente tipo descubran qué se rompió .

Answer 10

Como la mayoría de la gente ya ha dicho, sí, es mejor refactorizar y dejarlo más ordenado.

La refabricación ayuda a todos a mejorar, y todos deberían tener acceso a las herramientas de refactorización (Coderush para mí).

Sin embargo, si sus compañeros no están compartiendo el amor refactorización, entonces es una buena oportunidad para que los ilumine :)