Go проблемы с gofmt и diff / VCS?

Question

У меня есть вопрос об инструменте Go * gofmt , который автоматически форматирует вывод программ в соответствии с официальными спецификациями Go (например, вы не можете спорить о том, куда скобки должны идти в Go, потому что это очевидноисправлено спецификациями).

На следующей странице:

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

в пункте «Форматирование» написано, что:

В качестве примера, нет необходимости тратить время на выстраивание комментариев к полям структуры.Gofmt сделает это за вас.Учитывая объявление

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

gofmt выстроит столбцы в столбцы:

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

Однако я не понимаю, как это могло бы хорошо сочетаться с diff и VCSes.

Например, если бы у меня была новая строка:

confuzzabler int // doo doo be doo

и запустить diff , я должен получить это:

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

И жизнь была бы хорошей: разница показывает единственную измененную строку.

Однако, если я перезапущу gofmt , я получу это:

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

И теперь я перезапускаю diff и получаю это:

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
< 

Это очень запутанный и вводящий в заблуждение вывод diff , потому что только одна строкаизменилось.

Как вы справляетесь с этим как разработчик Go?

Answer 1

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

Что касается проблем с VCS, если бы вы форматировали код самостоятельно, следуя некоторому установленному соглашению (предположим, что здесь следует это соглашение gofmt), вы бы вручную переформатировали пробел в этом блоке кода точно так же, как gofmt сделал, и это изменение было бы засчитано любой VCS как изменение. Так что я не вижу никаких проблем с семантикой в ​​этом случае, на самом деле. Если вы вместо этого заботитесь о средствах сравнения, предоставляемых VCS, вам, вероятно, следует посмотреть, поддерживают ли они игнорирование изменений пробелов, как в упомянутом выше GNU diff. FWIW git diff поддерживает это с тем же параметром командной строки -b.

Answer 2

Стандарты ваших проектов на основе Go должны диктовать что-то вроде:

Перед тем как любой код Go будет передан в VCS, он форматируется с помощью gofmt. Это единственный приемлемый формат.

Тогда нет аргументов; если код проходит через gofmt без изменений, все хорошо. Если он изменяется при пропуске через gofmt, используйте вывод gofmt. То, что вы делаете во время редактирования, зависит от вас (с учетом других стандартов кодирования), но это требование для любого кода, зарегистрированного в вашей VCS.

Answer 3

Если это действительно беспокоит вас, сделайте две проверки.

При первой регистрации добавляется confuzzabler. Разумный комментарий: «Добавление новой переменной в T». Ваша разница будет изолирована от кода, который вы действительно изменили.

Затем выполните gofmt.

Второй коммит - это просто форматирование изменений, и разумным сообщением будет "gofmt". Здесь diff будет только кодом, который изменил gofmt.

Answer 4

Сравнивая результаты сравнения, видно, что произошло.Это не смущает и не вводит в заблуждение.