Идея взята с постов telegram-канала Cross Join

Представьте себе, что какой-то программист придет на работу в одних трусах. Или вообще голышом. Работа встала, все обсуждают происходящее, смеются или кривят лицо, никто не работает. Приходит руководитель и пытается что-то сделать.

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

Бред, правда? Ну да, слишком радикально. Пусть в целом люди ходят как хотят, и чувствуют себя хорошо. Исключительные ситуации нужно решать частным порядком (уволить хулигана?), ну в крайнем случае ввести правило, что кроме белья должно быть что-то еще.

И правда, бред. Ну а зачем тогда мы сами себе вводим бешеный фашизм в коде?

Слишком жесткие правила

Посмотрите правила code style. Стандарт PSR-12, например.

Вот несколько пунктов:

1. В конце каждого файла должен быть перевод строки. А если не будет, то кто умрёт?
2. Нельзя делать несколько statements на одной строке. Если я напишу $x = 1; $y = 1; $z = 1;, то читабельность ухудшится на 0.00001% и можно закрывать техотдел?
3. Declare statements MUST contain no spaces and MUST be exactly declare(strict_types=1). Ох, как всё серьёзно. Ни одного пробела, причем слово MUST капсом, чтобы все понимали степень ответственности. Если вставить где-нибудь пробел, то на код ревью никто код же прочесть не сможет!

Но блин, если один чудак однажды написал под воздействием каких-то веществ

declare(        strict_types                                              =1         )

то это еще не значит, что надо ВСЕХ бить плёткой ругать линтером за каждый пробел. Нужно просто вправить мозг ОДНОМУ чудаку. Готов поспорить, что именно он тогда пришел на работу без трусов.

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

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

Понятно, что есть способы автоматически отформатировать код по правилам. Вопрос в другом: какие правила нужны, а какие нет.

Почему это важно

Дома, когда ты пилишь свой pet-проект, ты используешь язык тот, какой хочешь, форматируешь код, как хочешь, структурируешь код, как хочешь. Точно не будешь надевать галстук.

И перформишь при этом как бог! Совершенно спокойно можно все выходные провести за кодингом и особо не устать.

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

Раньше мне казалось, что начальство перегибает палку ради дисциплины в вакууме, и меня от этого бомбило. Я это запомнил, и, став тимлидом, в своих командах стал применять демократию. Не навязывал от себя практически никаких правил. Тем не менее странные правила всё равно появлялись.

К примеру, в Go есть goimports, который форматирует код по стандарту, вшитому в стандартный тулинг. Казалось бы, о чем тут теперь спорить. Но все равно внезапно обнаруживаешь себя, переименовывающим getJson в getJSON и getById в getByID, иначе правило линтера N100500 скажет айайай. При этом читабельность если и меняется, то незначительно, и даже не ясно, в какую сторону.

Куча такого. Ладно код стайл, бог с ним. Давайте не будем на нем акцентировать внимание, это не настолько серьёзная проблема. Но ведь есть тысячи других радикальных штук. Договорились, что контроллеры тонкие, не содержат никакой логики — и всё, даже убогий код в контроллере из пары строк где-то в богом забытой части системы порождает споры на код ревью — является ли это логикой или нет.

Дофаминовый цикл "сделал задачу — получил удовлетворение" нарушен. Сделал задачу — получи звиздюлей от линтера и коллег на код ревью.

Дофамин еще полбеды. Возведение принципов программирования (тех же DRY или SOLID) в радикальный абсолют может привести к таким абстракциям, что код превращается в нечитабельное месиво. Увидел пару switch case — сразу городи иерархию классов. Так ведь в книжке написано.

Мы ругаем бешеный принтер, ограничивающий свободу, но сами часто действуем по принципу "запретить и не пущать".

Вообще, иногда хочется пересмотреть вообще всё. Например, однажды мы думали, как назвать по-английски переменную для ЦФО (центр финансовой ответственности). Словарь говорит, что это будет financial responsibility center. Если назвать переменную "FRC", то новичку будет непонятно, что это за хрень. В документации по продукту термин везде по русски, ЦФО. Если назвать financialResponsibilityCenter, то можно догадаться, о чем речь, но слишком длинно как-то.

Понятно, что никто не рискнет так делать, но идеально было бы так и назвать переменную русскими буквами — ЦФО. Если проект сугубо для русскоязычных людей и русскоязычных программистов, то почему нет? Просто потому что не принято, вот и всё. Рациональных причин мало, и с ними можно поспорить, как минимум в каком-то конкретном случае.

Вывод

Я считаю, что:

Придумывая универсальное правило, нужно убедиться, что оно точно капец необходимо.

Применяя универсальное правило, нужно смотреть на контекст, и уметь делать исключения. Потому что совсем универсальных правил не существует.

UPD. Для джуниор-программеров правила должны быть более жесткими, потому что важность читабельности кода для них может быть не столь очевидна.

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