2021 01 09 стандарты это не правила
Стандарты - это не правила
tags: #management
На самом деле, нет ничего хуже, чем углубляться в определение слов.
После предыдущей заметки по стандартизации показалось правильным поставить границу между двумя словами: стандарты и правила. Вопрос вызвало послесловие касательно автоматического форматирования и проверки кода, и это довольно хороший пример, чтобы показать разницу:
- линтер проверяет большое количество простых и/или понятных правил, чтобы найти ошибку;
- а вот команда договаривается о стандарте “качество кода” и устанавливаем линтер для того, чтобы его поддержать;
Более того, за этим двумя пунктами неизменно следует, что неизбежно появятся строчки вида
NOQA:
илиeslint-disable-line
, потому что они решают нужную задачу, но не в рамках правил. А вот в случае коллективного согласия, получится ситуация, в которой стандарт не был нарушен.
Кроме того, от правил требует следующих характеристик: простота, полнота и непротиворечивость. В противном случае, будут возникать противоречивые ситуации, и каждый будет трактовать ситуацию в свою пользу. Следующая проблема, которая следует из полноты, заключается в том, что такой подход ведёт в сторону увеличения их количества для максимальной детализации. Вот только количество ведёт к обратному эффекту, когда просто уже за всеми уследить не получится.
В следующий раз прежде чем писать правила, подумайте есть ли общие стандарты, которых вы хотите придерживаться, и если они не зафиксированы, то стоит начать именно с них.
Источники
- Возможно для кого-то спорный тезис про линтеры, посмотрите доклад “Интерактивный и холиварный доклад про линтеры”
- Honeypot Cult Article: The Importance of Team Standards… Or Not?
- О здравом смысле и правилах
- [[стандарты - это не правила]]