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


24

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?


8
él tiene razón, entonces, ¿por qué no hacer que todo el equipo use la herramienta de formato para guardar también, entonces todos obtendrán un código con un formato agradable que es fácil de leer y fácil de ver?
gbjbaanb

12
La mayoría de las buenas herramientas de comparación de archivos tienen un filtro para "diferencias sin importancia" o "ignorar espacios en blanco". Algunos, como Beyond Compare, se envían con filtros específicos de idioma preconstruidos. Úselo a su favor si lo tiene.
Michael K

77
El formato del código es tan importante como los cambios que se hicieron. La legibilidad tiene que ser una de las principales prioridades cuando estás en un equipo. Su VP debe saber eso y estar preocupado por eso.
Edgar Gonzalez

@Edgar: +1. El vicepresidente está siendo demasiado exigente. La legibilidad primero ... y una opción de ignorar espacios en blanco significa que esto no es gran cosa. Y también significa que hay un problema mayor porque al resto del equipo no le importa. El vicepresidente debería estar más preocupado por eso.
rapid_now

Respuestas:


41

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.


todavía no ayuda si desea comparar los cambios de varias revisiones anteriores, pero es mejor que el cambio de código + los cambios de formato de una vez. Por supuesto, esta respuesta también se aplica a la refactorización.
gbjbaanb

1
+1: Además de esto, es bueno usar algo como Stylecop o alguna otra herramienta que autoformata y refuerza el estilo. Luego, sincronice la configuración entre todos los miembros del equipo para que el formato sea consistente para todos y no necesariamente tenga que recordar cuál es la regla de formato "correcta".
Ryan Hayes

3
Si el OP fue reprendido por intentar formatear un documento, algo me dice que no podría sugerir usar StyleCop.
Wayne Molina

3
@gbjbaanb: Sí. Por eso es mejor tomar este tipo de decisiones desde el principio. El proyecto en el que estoy ahora tiene la configuración del formateador de Eclipse registrada en el repositorio para que sepamos que todos tienen la misma configuración.
unholysampler

1
@quickly_now: Por eso tenemos gerentes con derechos de veto. Si las personas no pueden ponerse de acuerdo, pueden tomar una decisión.
unholysampler

29

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.


3
Además, también es una buena práctica decidir sobre una determinada convención de formato entre su equipo. No solo formatee el código de otras personas sin discutir esto primero.
Steven Jeuris

Sí ... Pero ya sabes, a veces es tan tentador formatear ese maldito desastre "mientras estás en eso". Además, tratar de separar los cambios cosméticos de los cambios funcionales puede ser un dolor si usa VS y formatea algo automáticamente. Ah, y nadie dirá que está formateando algo estúpido mientras tiene Tareas muy importantes que hacer mirando el historial de confirmaciones
Dyppl

10

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.


3
Creo que esta es la mejor solución para su situación actual, pero debe hablar sobre ello con su equipo. Sin embargo, tiene un problema mayor, que es la falta de un estándar de codificación.
Thomas Owens

2
Convenido. Me pregunto si el entorno del OP es uno de esos lugares de vaqueros donde los estándares se evitan para "poner las cosas rápidamente".
Wayne Molina

4

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

Siempre que no incluya etiquetas VC en el binario (o información de compilación).
Vatine

2

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.


"A sus espaldas": esto se remonta a los problemas psicológicos de la propiedad del código (o la guerra territorial de desarrollo).
rwong

2
El "código de otras personas" es una forma interesante de decirlo. Trabajo en el producto de mi compañía, compilado a partir del código que posee mi compañía, en el que trabajamos los miembros de mi equipo y yo. No está a sus espaldas de ninguna manera para fijarlo a los estándares mientras se trabaja en él. Sin embargo, estoy de acuerdo en que la solución ideal es hacer que el desarrollador original lo limpie al estándar.
Caleb Huitt - cjhuitt

@Caleb: Se pone difícil si simplemente rechazan la basura.
rapid_now

Por "código de otras personas" no me refiero a la propiedad, me refiero a algo que escribieron y creo que todavía son responsables de apoyar. En ausencia de estándares de codificación, si implemento una clase con 1,000 líneas de código y realiza cambios en 2 líneas para corregir algún comportamiento y formatear todo el archivo, me sorprenderé mucho cuando abra el archivo. Como miembros de un equipo, no debemos hacernos eso el uno al otro. Si revisas ese archivo con un reformateo completo y ni siquiera me avisas, eso no es muy amigable para el equipo.
cdkMoose

En la discusión original de OP, leí que para ser un entorno sin estándares de codificación (o que no se aplica bien), es por eso que respondí como tal. En ese entorno, un desarrollador no debería imponer sus estándares a los demás.
cdkMoose
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.