Пользуетесь ли вы линтерами в Go
Что проверяют
Есть ли у вас привычка к статическому анализу и понимаете ли вы, что в Go часть этой работы уже встроена в тулчейн. Заодно смотрят, умеете ли вы жить с линтером в большом проекте: не отключать всё подряд и не заваливать ревью сотнями замечаний.
Как отвечать
Начните с того, что идёт из коробки: gofmt или gofumpt приводит код к единому виду, go vet ловит подозрительные конструкции и запускается вместе с go test. Дальше внешние инструменты:
staticcheck: самый полезный набор, находит мёртвый код, бессмысленные сравнения, ошибки в работе со временем и строками;errcheck: непроверенные возвращаемые ошибки, больная тема Go;errorlint: неверная работа с обёрнутыми ошибками, сравнение значением вместоerrors.Is;revive: стилевые правила, живая замена заархивированномуgolint;bodyclose,sqlclosecheck,gosec: незакрытые ресурсы и небезопасные места.
На практике всё это запускается одним агрегатором golangci-lint с конфигом в репозитории, и тот же конфиг используется в CI и в хуке перед коммитом, чтобы локальный и серверный результат совпадали. Скажите про режим проверки только новых изменений: на унаследованном коде это единственный способ включить строгие правила, не переписывая всё разом. Ложные срабатывания гасятся точечным //nolint с указанием правила и причины, а не выключением линтера целиком.
Где спотыкаются
Называют golint действующим инструментом. Он давно заморожен, вместо него берут revive или staticcheck. Туда же gofmt, который зовут линтером: он форматтер и ничего не находит.
Включают сразу все линтеры на старом проекте, получают лавину предупреждений, сборка становится вечно красной, и правило тихо выключают. Рабочий путь: базовый набор, затем расширение по одному линтеру.
Путают статический анализ с проверками во время выполнения. Линтер не увидит гонку данных, для этого нужен запуск тестов с детектором гонок, а утечку горутин ловят отдельной библиотекой. Ответ в духе «у нас есть линтер, значит с конкурентностью всё хорошо» тянет за собой неприятный уточняющий вопрос.