Почему "nit" — это плохо?

В код-ревью периодически применяются комментарии типа “nit”. Обычно ими обозначают места, которые можно сделать лучше, но это не критично. Чаще всего такие комментарии касаются вопросов стиля или оформления кода. Также в категорию “nit” попадают частные мнения ревьюеров, которые не влияют на качество конечного результата.

В статье автор показывает, что на самом деле nit не так прост, как кажется, и почему такие комментарии могут даже вредить. Он проанализировал 25 000 nit-комментариев, чтобы понять, к чему они относятся и насколько они на самом деле являются nit.

⭐️ Интересные идеи

➡️ В целом термин nit трактуется очень широко, поэтому и применяться может разными людьми по-разному. То, что для одного — мелочь, для другого может быть принципиальным вопросом (табы vs пробелы).

➡️ Чаще всего nit-комментарии касаются форматирования: точек с запятыми, пробелов и так далее (god bless gofmt). На втором месте находится организация кода, на третьем — написание документации и комментариев.

➡️ Многие nit-комментарии можно убрать, настроив линтеры и автоформаттеры кода. Даже логику можно покрыть линтерами (например, поставить ограничения на длину функции или количество логических ветвлений).

➡️ Основная беда nit-комментариев заключается в том, что комментарии дорого стоят с точки зрения разработки. Одному человеку нужно проанализировать код и написать комментарий, другому — проанализировать комментарий и внести изменения или аргументировать отказ от этого (и пошло-поехало). Хорошо настроенные форматтеры и линтеры могут заметно ускорить и упростить код-ревью.
Приятного чтения!

#programming@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи