Статический анализ в Go: как мы экономим время при проверке кода

[powerman]

Спасибо за наводку на golangci-lint, реально раз в 5 быстрее gometalinter. Ну и настраивать его через конфиг удобнее.

[Artem_zin]

форматтинг можно засунуть в pre-commit hook (есть нюансы, но в целом норм), одной бесякой будет меньше)

[aml]

Форматтинг (вместе с goimports) удобно засовывать в on-save hook в редакторе.

[Artem_zin]

это несомненно вариант, но в команде побольше он проблематичный :(

разработчики используют разные ide/редакторы, автоматический провиженинг ide/редакторов может далеко не всем понравиться

[aml]

О, кстати, а вы не знаете способ, как автопровижнить pre-commit hook в git?

[Artem_zin]

Совсем автоматически никак, только если в гите нет уязвимости через которую это можно сделать)

Если у вас есть Makefile или другой похожий энтрипоинт, можно через него, я делаю так, раскатывает на примерно 50 человек, всё ок

[jirfag]

Спасибо за статью и использование golangci-lint, я, как его автор хотел бы дополнить двумя пунктами:

1. Рекомендую устанавливать фиксированную версию, а не через go get (увидел это в докерфайле): так билды в CI будут стабильнее при улучшении существующих линтеров
2. Есть классные опции --new/--new-from-rev: они здорово помогают интегрироваться в крупные проекты — ошибки ищутся только в новом коде. Например, так смогли применить golint в GoogleContainerTools/skaffold.

И было бы здорово ссылку на проект добавить, по аналогии с goreporter и gometalinter.

[m1nor]

Спасибо за комментарии и прекрасный инструмент :) Добавил ссылку, зафиксировал версию в контейнере.

[powerman]

Стабильные билды в CI важны только тогда, когда линтеры не важны. Типа, формально мы линтеры используем, но на практике в коде сплошной //nolint и версия линтера устарела на пару лет.

Я предпочитаю другой подход, при котором ошибки линтеров ничем не хуже ошибок тестов. Тесты могут поломаться из-за обновления зависимостей, равно как и из-за обновления используемых инструментов — в первую очередь самого Go, но так же и линтеров. Поломался билд в CI — ну так почини. Из-за обновления линтера? И что? Ты не виноват??? Не виноват, да. Тебя никто и не виноватит. Просто почини, раз сломалось именно на твоём PR, и двигайся дальше. В крайнем случае, если сейчас полноценно чинить нет времени — добавь исключение в линтер и таску в бэклог чтобы исключение удалить.

В общем, не понимаю я этой паники насчёт стабильных версий в CI. Всё, что попадает в master (я сейчас про master-ветку линтера) — должно быть достаточно стабильным чтобы им пользоваться, это навязано стилем разработки на Go да и вообще здравая идея. А штатные изменения в поведении линтеров, которые не являются багами самих линтеров — вполне приемлемы и в CI.

[dobriykot]

А за счет чего golangci-lint быстрее gometalinter? Не потому, случайно, что megacheck выключен по умолчанию? На gometalinter именно он у меня обычно в таймауты не влезает.

[jirfag]

оу, в ридми ошибка, megacheck по умолчанию включен, спасибо. И, действительно, megacheck это самый медленный линтер.
golangci-lint быстрее за счет того, что:

1. Он загружает программу и проверяет ее типы только 1 раз: это 80% работы большинства линтеров.
2. Он парсит AST дерево не для каждого линтера: для части линтеров переиспользуется уже распаршенное дерево. В плане делать это для всех.
3. Нет создания процессов и использования больше потоков, чем доступно процессоров или указал пользователь. С запущенным gometalinter из-за этого, в частности, за ноутом невозможно работать: он есть все ядра, в не столько, сколько ему указал.
4. Умный планировщик линтеров, учитывающий их время выполнения

[dobriykot]

Круто! Теперь понятно, спасибо.