Formatear código algo malo cuando se usa un VCS?

Casi siempre formateo mi código antes de comprometerme para asegurarme de que se haga correctamente. La mayoría de mi equipo realmente no se preocupa y no siempre formatea su código correctamente (cosas menores que no afectan el código pero afectan la legibilidad cuando se trata de mantenerlo).

Recientemente instalé las herramientas eléctricas VS que tienen la opción "Formatear al guardar", e hice un cambio a un archivo que no estaba formateado anteriormente. El vicepresidente de desarrollo se me acercó y me reprendió por el formato, ya que aparece en la herramienta de fusión como si hubiera cambiado casi todo el archivo, en lugar de solo una o dos líneas (por lo que no puede ver exactamente lo que modifiqué fácilmente), y me dijo que deshabilitara el formato al guardar en el futuro. Si bien entiendo esa preocupación, a veces me resulta difícil clasificar el código que no está formateado, y de todos modos, la OMI debe formatearse correctamente todo el tiempo. Tenga en cuenta que no solo estoy formateando las cosas por capricho, sino que mientras escribo el código, usaré la herramienta eléctrica o presionaré el comando de teclado para formatear el texto para que sea más fácil de leer, y en SVN esto aparece como Una modificación.

Entonces pregunto, ¿formatear el código siempre es algo malo? ¿Son sus preocupaciones más válidas que asegurarse de que el código sea legible?

En primer lugar, su equipo necesita elegir una convención de formato y seguirla. Debe llegar a un acuerdo y hacer que todos lo cumplan para que no haya personas que luchen por cómo deberían ser las cosas. Esto no debería ser algo que haces solo.

En cuanto a tu verdadera pregunta. Formatear código no es algo malo. Lo que es malo es realizar cambios importantes de formato en la misma confirmación que los cambios de código. Cuando su equipo llegue a un consenso sobre cómo se deben formatear las cosas, haga una pasada a través del código y formatee todo. Comprueba eso por sí mismo. El mensaje de confirmación dejará en claro que los cambios son solo espacios en blanco y no funcionales. Luego, cuando necesita hacer cambios funcionales, están en una confirmación diferente para que puedan verse claramente.

No, el código de formato es muy importante . Sin embargo, las confirmaciones deben realizarse en dos grupos:

1. Cambios cosméticos : cualquier cosa que haga que el código sea más legible.
2. Los otros cambios , todo lo demás que afecta el código.

Use el mensaje de confirmación para indicar que solo se han cambiado los cosméticos. Estos se pueden omitir fácilmente al buscar modificaciones más sustanciales.

Ambos tienen un punto, pero ambos pueden obtener lo que quieren. Primero formatee el código, verifique ese cambio solamente. A continuación, realice sus cambios funcionales y verifíquelo como un segundo paso.

También soy un selector de formato, así que aquí hay algunos consejos:

• Primer paso requerido: haga que el equipo acuerde algunos estándares básicos de formato, como pestañas versus espacios, posiciones de llaves, estilos de comentarios, etc. Ahora sus cambios de formato no serán una sorpresa completa para todos, y usted no dará un paso en cualquier dedo del pie.

• Limpie el formato solo alrededor del código que cambia. Si realiza cambios en una sola función, limpie esa función. Al menos con el tiempo tendrás un código más atractivo.

• Realice revisiones importantes de formato como una confirmación por separado, sin otros cambios de código. Solo debe hacer esto cuando sea menos probable que desee comparar el código después del cambio antes del cambio, ya que comparar un diferencial como ese puede ser molesto. Usualmente hago limpiezas como lo primero antes de un desarrollo importante en ese código.

• Obtenga una buena herramienta de diferencias que pueda hacer un marcado dependiente del idioma de cambios significativos y cambios no significativos. Mi diff favorito también, Beyond Compare, marca los cambios reales del código en un color y las diferencias de espacio en blanco / comentario solo en otro.

editar para un consejo más:

• Varía de un idioma a otro, pero para la mayoría de los cambios cosméticos en el código, debe poder comparar los binarios compilados antes y después de una limpieza importante para estar absolutamente seguro de que no lo arruinó.

No debe volver a formatear y confirmar cambios en el código de otras personas a menos que:

• usted es el gerente que intenta establecer estándares de codificación del equipo
• su gerente le ha pedido que limpie el código para cumplir con los estándares de codificación del equipo
• estás limpiando el código de un desarrollador que ya no está en tu equipo para cumplir con los estándares de codificación del equipo.

Notarás en todos los casos que me refiero a los estándares de codificación del equipo. Creo firmemente en los estándares de codificación razonables y acordados para el equipo. Si los tiene, entonces el desarrollador original debe regresar y limpiar su código para cumplir con los estándares del equipo, no debe hacerlo a sus espaldas. Si no tiene estándares (y debería hacerlo), entonces no debería modificar el código de otro miembro del equipo para adherirse a sus filosofías, especialmente a sus espaldas. Recuerde, usted es parte de un equipo y aunque los estándares de codificación son importantes, también lo son la confianza y el respeto entre los miembros del equipo.