Приведи пример самого частого комментария в код-ревью

Что проверяют

Проходите ли вы ревью всерьёз и знаете ли свои слабые места. Вопрос личный: интересен не список хороших практик, а то, что указывают лично вам чаще всего и что вы с этим сделали.

Как отвечать

Назовите один или два повторяющихся комментария и доведите до вывода. В Go повторяются вполне конкретные вещи:

• ошибки: проглоченная ошибка, потерянный контекст при оборачивании вместо fmt.Errorf("что делали: %w", err), ошибка, которую и залогировали, и вернули наверх, отчего в логах она появляется дважды;
• контекст: не пробросили в вызов, положили в структуру вместо первого аргумента, запустили фоновую горутину без отмены;
• горутины без хозяина: непонятно, кто их завершит, нет WaitGroup или errgroup, при выходе остаётся утечка;
• ресурсы: defer resp.Body.Close() до проверки ошибки, defer внутри цикла;
• интерфейсы объявлены рядом с реализацией, а не у потребителя, и сразу на десяток методов.

Сильный ответ добавляет, что сделано, чтобы комментарий перестал повторяться: подключили линтер в CI, договорились о едином способе оборачивать ошибки, завели короткий чек-лист перед отправкой изменений. Про чужой код скажите отдельно: замечание пишется к коду, а не к автору, и обязательное в нём отделено от вкусового.

Где спотыкаются

Отвечают, что замечаний обычно не получают. Либо ревью в команде формальное, либо человек их не слышит, и оба вывода хуже честного разбора своей типичной ошибки.

Называют одну косметику: пробелы, порядок импортов, длину строки. В Go этим занимается gofmt и линтер, так что такой ответ означает лишь то, что инструменты в проекте не настроены.

Держат оборону и рассказывают, как отстаивают свой вариант. Ревью не суд, и быстрое согласие по непринципиальному вопросу ценится выше умения спорить до последнего.