Немного холиварная тема про правила (линтеры, тесты и т.д).

Я считаю, что правила нужны, но только когда они нужны. Ваш кэп.

Программисты почему-то делятся на два лагеря, одним вообще всё по барабану и любой говнокод норм, а другие наоборот упарываются: 100% покрытие тестами, всё обложено линтерами, которые тебя затрахают до полусмерти.

Взять например, пункты из PSR-12 (стандарты языка PHP).

1) All PHP files MUST end with a non-blank line, terminated with a single LF.

А что будет-то, если я допущу еще одну пустую строку в конце файла? Читабельность ухудшится, может быть?

2) Declare statements MUST contain no spaces and MUST be exactly declare(strict_types=1) (with an optional semi-colon terminator).

Оу, а если я не дай бог перед скобкой поставлю пробел? Другой программист команды будет понимать этот код с эффективностью на 0.0001% меньше, это превратится в легаси?.

Да ни фига. Это просто отсутствие системного подхода. Мы почему-то поставили единообразие как абсолютную ценность. При этом остальные параметры системы проигнорировали. Например, дофаминовая радость от выполненной задачи может быть уменьшена необходимостью считать бессмысленные пробелы и переводы строк перед тем как отправить код на ревью. (если есть автофиксер - это ок, но обычно они не всё могут)

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

Точно также и с Go. Казалось бы, в нем встроены инструменты gofmt / goimports, что еще надо, однако всё равно, если вы посмотрите любой реальный проект, там будет дописана куча сомнительных правил для линтера. Например, что надо писать getJSON вместо getJson (ну, или наоборот). Оба написания легко читаются, тут не нужно особое правило.

Я не знаю, почему так, но это прям повсеместная проблема. Мы решаем какую-то боль (большое разнообразие в коде разных людей), возводим эту боль в 100% абсолют и забываем про проблемы системы в целом.

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

Например, мантра, что контроллер должен быть ВСЕГДА настолько тонким, насколько это возможно, приведет к тому, что даже пара лишних строк, нормально читаемых, строк, которые никто и никогда не будет переиспользовать и не собирался, приведут к спорам на код ревью и исправлениям. Потому что порядок-то нужон. Т.е. вместо правил "код должен быть понятен" и "все важные места протестированы", вводятся правила по тонкости контроллеров, переиспользуемости классов и т.д., что выливается в 100 слоёв абстракции в участке кода, который правится-то раз в год и в целом не особо что делает полезное.

Ну или switch / case, одинаково используемый в двух местах, всегда ли надо переделывать на иерархию классов? Ну нет, it depends. Во главе угла - общая читаемость и гибкость кода, а в еще большем углу - деньги бизнеса. Важна система в целом. Непонимание этого часто приводит к паттернам головного мозга.

Про системный подход я еще обязательно напишу отдельный пост, так что не забудьте подписаться на канал