Formato de código y diferencias de control de origen

Question

¿Qué productos de control de origen tienen una facilidad "diff" que ignora el espacio en blanco, llaves, etc., al calcular la diferencia entre las versiones registradas? Me parece recordar que la diferencia de Clearcase hizo esto, pero Visual SourceSafe (o al menos la versión que utilicé) no lo hizo.

La razón por la que pregunto es probablemente bastante típica. Cuatro desarrolladores perfectamente razonables en un equipo tienen cuatro formas completamente diferentes de formatear su código. Al revisar el código modificado por otra persona, cada uno ejecutará inmediatamente algún tipo de macro de programa o editor para formatear las cosas de la forma que prefiera. Realizan cambios de código reales. Ellos registran sus cambios. Se van de vacaciones. Dos días después, ese programa, que había estado funcionando bien durante dos años, explota. El desarrollador asignado al error hace una diferencia entre versiones y encuentra 204 diferencias, de las cuales solo 3 tienen importancia, porque el algoritmo diff es cojo.

Sí, puede tener estándares de codificación. La mayoría de las personas los encuentran terribles. Una solución en la que todos puedan comer su pastel y comerlo también parece mucho más preferible.

=========

EDIT: Gracias a todos por unas sugerencias.

Lo que llevo de esto es:

(1) Un sistema de control de origen con es preferible plug-in diffs tipo.

(2) Encuentre una diferencia con las opciones adecuadas.

(3) Utilice un buen programa de formato de fuente y establezca un estándar de facturación.

Suena a plan. Gracias de nuevo.

Answer 1

Quizás debería elegir un formato y ejecutar alguna herramienta de sangría antes de registrarse para que cada persona pueda verificar, volver a formatear sus preferencias, hacer los cambios, volver a formatear el estándar oficial y luego registrarlo?

Un par de pasos adicionales, pero ya usan herramientas de sangría al trabajar. Tal vez puede ser un script de check-in desencadenado?

Editar: esto también podría resolver el problema de la abrazadera.

(No he probado esta solución yo mismo, de ahí los "perhapes" y "maybes", pero he estado en proyectos con los mismos problemas, y es un dolor tratar de pasar por dificultades con cientos de irrelevantes cambios que no están limitados a espacios en blanco, sino que incluyen el formato mismo.)

Answer 2

Subversion aparentemente admite esto, ya sea de forma nativa en las últimas versiones, o mediante el uso de un diff alternativo como Gnu Diff.

Answer 3

Git tiene estas opciones:

• --ignore-space-at-eol

  ignorar los cambios en los espacios en blanco en EOL.

• -b, --ignore-space-change

  Ignorar cambios en la cantidad de espacio en blanco.Esto ignora los espacios en blanco al final de la línea, y considera que todas las demás secuencias de uno o más caracteres de espacio en blanco son equivalentes.

• -w, --ignore-all-space

  Ignorar espacios en blanco cuando se comparan las líneas. Esto ignora las diferencias incluso si una línea tiene espacios en blanco donde la otra línea tiene ninguno.

no estoy seguro de si los cambios aparato ortopédico puede ignorarse usando diff de Git.

Si se trata de un código C/C++, puede definir las reglas Astyle y luego convertir el estilo de llave del código fuente al que desee, usando Astyle. A git diff producirá una salida sana.

Answer 4

Beyond Compare hace esto (y mucho más) y puede integrarlo en Subversion o en Sourcesafe como una herramienta de diferencia externa.

Answer 5

Como se explica en Is it possible for git-merge to ignore line-ending differences?, es más una cuestión asociar la herramienta diff correcta a su VCS favorito, en lugar de confiar en la opción VCS correcta (incluso si Git tiene algunas opciones con respecto al espacio en blanco, como la mencionada en Alan's answer, siempre no será tan completo como a uno le gustaría).

DiffMerge es lo más completo en esas opciones de "ignorar", ya que no solo puede ignorar espacios sino también otras "variaciones" basadas en el lenguaje de programación utilizado en un archivo determinado.

Answer 6

Elija un estándar de codificación (espantoso), escríbalo en algún documento oficial de normas de codificación y continúe con su vida, jugando con espacios en blanco no es un trabajo productivo.

Y recuerde que usted es un desarrollador profesional, su trabajo es realizar el proyecto, cambiar cualquier cosa en el código debido a una preferencia de estilo personal daña el proyecto; no solo hará que difijar sea más difícil, también puede introducir Es difícil encontrar problemas si el formateador de origen o el compilador tiene errores (y su herramienta de diferencias no le salvará cuando dos compañeros de trabajo comiencen a pelear por la carcasa).

Y si alguien no está de acuerdo para trabajar con el estilo seleccionado solo él (o ella) recordarle que es la programación como una profesión no como un pasatiempo, ver http://www.ericsink.com/entries/No_Great_Hackers.html