Comments 30
greabock, dimsog,
Не завидую разрабам, которые к вам будут приходить или от вас уходить. Весь мир пишет по PSR.

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

P.S. Хабр упорно перемещает мой комментарий не в ту ветку, написал в саппорт.

PSR — всего лишь рекомендации — вы не обязаны их соблюдать.
GRASP — всего лишь шаблны — вы не обязаны их использовать.
SOLID — всего лишь принципы — вам не обязательно им следовать.


Подпишусь под каждым утверждением.


А еще никто вас никто и никогда не обяжет и соблюдать элементарный этикет, отказаться от подворотов в минус двадцать и использовать презервативы при случайных связях. Нет таких законов.

PSR — всего лишь рекомендации — вы не обязаны их соблюдать.
GRASP — всего лишь шаблны — вы не обязаны их использовать.
SOLID — всего лишь принципы — вам не обязательно им следовать.

Принципы проектирования основываются на ± общепринятых конецпциях делающих код проще в поддержке, вроде внутренней/внешней связности модулей(coupling/cohesion), information hiding.

От несоблюдения PSR, связность не повысится, лишний код не появится(а то и уберётся), поддерживать его тяжелее не станет, а может и легче станет, с лучше отражающими реальность интерфейсами(а не логгер который никогда не бросает исключения по интерфейсу, даже если они критичны), нормальным неймингом.

Нет таких законов

А я не про законы, я про практическую ценность конкретных ограничений.

PSR — это и есть ± общепринятый стандарт.


Поддерживать код тяжелее не станет

Если код сложнее читать — его сложнее поддерживать. Читать его сложнее программисту, который привык писать по стандарту (с долей вероятности превышающей 50% — PSR) отличному от стандарта который вы используете.


И да, если ваш логгер бросает исключения, которые (внезапно!) должны логироваться, то честное слово — у вас проблемы побольше чем выразительность PSR. И, пожалуй, я могу понять если это легаси, с которым приходится жить. Но в новых проектах так делать нельзя.

Даже если это в легаси, надо покарать того, кто это наследие оставил.
Легаси разное бывает, иногда такое древнее, что и карать как бы и не за что. В те времена, когда охотились на мамонтов, так было принято.
И да, если ваш логгер бросает исключения, которые (внезапно!) должны логироваться, то честное слово — у вас проблемы побольше чем выразительность PSR. И, пожалуй, я могу понять если это легаси, с которым приходится жить. Но в новых проектах так делать нельзя.

Что не так с требованиями бизнеса не проводить операцию при невозможности записать лог?

Если код сложнее читать — его сложнее поддерживать. Читать его сложнее программисту, который привык писать по стандарту (с долей вероятности превышающей 50% — PSR) отличному от стандарта который вы используете.

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

Стандарты PSR — не безоговорочный идеал.

PSR — это и есть ± общепринятый стандарт.

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

С требованием бизнеса всё норм. Только вот это уже не логгер. Потому что логгер не про бизнес вообще.


Я попробую метафорой.


Атомарное действие в php (будь то HTTP запрос или какая-консольная команда, если она не демон). Это как поезд который идет из точки А в точку Б.


Логгер — это как самописец в поезде. Вы же не станете жать экстренное торможение, только потому что самописец отказал? Вы даже не можете знать, что он отказал.


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


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


Возвращаясь к миру PHP: Вы пытаетесь реализовать транзакции — это хорошо. Вы не можете отличить логирование от транзакционных операций — это плохо.

Что не так с требованиями бизнеса не проводить операцию при невозможности записать лог?

Вероятно бизнесу на самом деле нужен не лог, а какой-нибудь audit trail.
Это совсем другая подсистема, которая лишь похожа на лог.
if ($user === null) { // $user является типом object
    // ...
}
if ((int)$request->postData('amount') === 100) {
    // ...
}
if ($booking->comment === '') {
    // ...
} 

А можно пояснить, откуда особый случай во втором варианте?
Почему для именования файлов и папок предлагается кебаб-кейс? Вроде бы это естественно для джаваскриптовых языков и идёт ещё от html-атрибутов, но для серверного языка? Чтобы в URL были минусы вместо подчёркиваний, что ли?

Не завидую разрабам, которые к вам будут приходить или от вас уходить. Весь мир пишет по PSR.

Главное, что у них есть свой прописанный и обязательный Code Style. Иногда бывает, что его нет и каждый городит, что хочет.

Разных code-conventions много, но такие, где были бы еще и аргументы по каждому требованию — это редкость. А предложенное в статье выделяется из общей массы лишь тем, что местами противоречит PSR. Возникает очень много «почему» практически по каждому пункту.
Всегда не любил четкие правила написания кода. Особенно обязательные. Может кто знает утилиты, позволяющие каждому разработчику видеть свое оформление, вместо того чтобы привыкать к корпоративному? Желательно так, чтобы при сохранении форматировалось в корпоративный вид, и возможно даже была подпись как переобозвать переменную для корпоративного варианта.
Запрещены отрицательные логические названия
Почему? Меня лично раздражает выискивать глазами восклицательный знак и в уме инвертировать условие. Особенно, если надо в одном IF'е проверить пару условий.

Другое дело, если условия с отрицанием поддерживаются в самом языке:
if ($component->enabled()) { 
    print "OK"; 
}

unless ($component->enabled()) {
    print "Whoops";
}
тогда да, правило становится полезным.
Если условие является большим, то обязательно выделить его в одно или несколько смысловых выражений и использовать его (их) в условии.

В приведённом «хорошем» примере всегда будут вычисляться все три условия, тогда как в «плохом» достаточно одного, принимающего значение false. Мелочь, но иногда может сыграть. Думаю, такое вообще не должно относиться к стилю кода.
Для этого достаточно переменные заменить на методы. Сохранится и читаемость и ленивые вычисления
Там предлагается заменять таким образом сложные условия. Весьма вероятно, что если выделить сложное условие в метод, то придётся в этот метод передать значительное количество локальных переменных, и условие всё равно будет громоздкое.

Вот то, как это приведено в примере — это неплохое решение для кода, реализующего запутанную, не очень интуитивную бизнес-логику. Я и сам так делал, когда каждое из условий вычисляется относительно легко, читаемость просто супер. Просто делать так или нет — зависит от конкретной ситуации, а в этом code style это указано как требование, что не очень хорошо, на мой взгляд.
UFO landed and left these words here
Мне тоже это требование не понравилось. Я ещё понимаю, если бы это была рекомендация: «ребята не делайте так, если думаете что здесь нужны объяснения, то лучше рефакторите». Скрипты со нестандартной бизнес-логикой вообще надо документировать внутри. Любая строка, которая потенциальна похожа на ошибку, должна быть обоснована комментарием, а то потом кто-нибудь залезет и по незнанию оптимизирует. Любую какую-то формулу, какие-то условные действия — всё лучше пояснять и в идеале отсылать к задачам или документам. Комментарии — добро, а вовсе не признак плохого кода.
Only those users with full accounts are able to leave comments. Log in, please.