¿Tiene problemas con gofmt y diff / VCS?

Tengo una pregunta sobre la herramienta gofmt de Go, que formatea automáticamente la salida de los progtwigs de acuerdo con las especificaciones oficiales de Go (por ejemplo, no se puede discutir sobre dónde deben ir los corchetes en Ir, porque eso aparentemente está corregido por las especificaciones).

En la siguiente página:

http://golang.org/doc/effective_go.html 

en el párrafo "Formato", está escrito que:

Como ejemplo, no hay necesidad de perder time alineando los comentarios en los campos de una estructura. Gofmt lo hará por ti. Dada la statement

 type T struct { name string // name of the object value int // its value } 

gofmt alineará las columnas:

 type T struct { name string // name of the object value int // its value } 

Sin embargo, no entiendo cómo esto podría jugar bien con diff y VCSes.

Por ejemplo, si tuviera una nueva línea:

 confuzzabler int // doo doo be doo 

y ejecutar un diff , debería get esto:

 2d1 < confuzzabler int // doo doo be doo 7d5 < 

Y la vida estaría bien: la diferencia muestra la única línea que cambió.

Sin embargo, si vuelvo a ejecutar el gofmt , tengo esto:

 type T struct { confuzzabler int // doo doo be doo name string // name of the object value int // its value } 

Y ahora vuelvo a ejecutar diff y entiendo esto:

 2,4c2,3 < confuzzabler int // doo doo be doo < name string // name of the object < value int // its value --- > name string // name of the object > value int // its value 7d5 < 

Que es una salida diff altamente confusa y engañosa porque solo una línea cambió.

¿Cómo lidiar con esto como un desarrollador Go?

 $ diff --help|grep -i white -b --ignore-space-change Ignore changes in the amount of white space. -w --ignore-all-space Ignore all white space. 

En cuanto a los problemas con VCS, si estuviera formateando el código usted mismo siguiendo alguna convención establecida (supongamos que esta convención es lo que gofmt sigue) habría reformateado manualmente el espacio en blanco en ese bloque de código exactamente de la manera en que gofmt hizo, y este cambio han sido contados por cualquier VCS como un cambio. Así que no veo ningún problema con la semántica en este caso, realmente. Si, en cambio, le importan las diferentes herramientas provistas por los VCS, probablemente deba comprobar si admiten ignorar los cambios en el espacio en blanco, como lo hace el diff de GNU mencionado anteriormente. FWIW git diff admite esto con la misma opción de línea de command -b .

Sus estándares de proyectos basados ​​en Go deberían dictar algo como:

Antes de que un código Go se gofmt en el VCS, se formatea con gofmt . Este es el único formatting aceptable.

Entonces no hay argumento; si el código pasa a través de gofmt sin cambios, todo está bien. Si cambia cuando pasa a través de gofmt , entonces use la salida de gofmt . Lo que haga durante la edición depende de usted (sujeto a los otros estándares de encoding), pero este es un requisito para cualquier código registrado en su VCS.

Si esto realmente te molesta, haz dos checkins.

El primer check in agrega confuzzabler . Un comentario razonable es "Agregar nueva variable a T". Su diff estará aislado del código que realmente ha cambiado.

Luego, realiza gofmt.

El segundo compromiso es simplemente formatear los cambios y un post de compromiso razonable sería "gofmt". La diferencia aquí será solo el código que gofmt ha cambiado.

Comparando la salida de diff, es obvio lo que sucedió. No es confuso ni engañoso.