Pregunta ¿Problemas de gofmt y diff / VCS de Go?


Tengo una pregunta sobre Go's gofmt herramienta, que formatea automáticamente la salida de los programas 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

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

Como ejemplo, no hay necesidad de gastar tiempo en alinear los comentarios en   Los campos de una estructura. Gofmt hará eso por ti. Dado que   declaración

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 ejecuta un diff, Debería obtener esto:

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

Y la vida sería buena: la diferencia muestra la única línea que se 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 altamente confuso y engañoso diff salida porque solo una linea cambia

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


5
2017-09-08 13:08


origen


Respuestas:


$ 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 estaba formateando el código usted mismo siguiendo alguna convención establecida (supongamos aquí que esta convención es qué gofmt sigue) habrías reformateado manualmente el espacio en blanco en ese bloque de código exactamente de la manera gofmt hizo, y este cambio habría sido contado por cualquier VCS como un cambio. Así que no veo ningún problema con la semántica en este caso, de verdad. 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 apoya esto con el mismo -b opción de línea de comando.


5
2017-09-08 15:25



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

Antes de que cualquier código de Go se comprometa con el VCS, se formatea con gofmt. Este es el único formato aceptable.

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


5
2017-09-08 15:32



Si esto De Verdad te molesta, haz dos controles.

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, realice gofmt.

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


1
2017-09-08 18:27



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


0
2017-09-08 14:12