PHP Code Style Conventions

[dimsog]

PSR

[EvgeniiR]

greabock, dimsog,

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

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

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

[greabock]

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

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

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

[EvgeniiR]

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

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

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

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

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

[greabock]

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

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

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

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

[a-tk]

Даже если это в легаси, надо покарать того, кто это наследие оставил.

[Alroniks]

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

[EvgeniiR]

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

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

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

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

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

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

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

[greabock]

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

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

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

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

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

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

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

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

[Fortop]

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

Вероятно бизнесу на самом деле нужен не лог, а какой-нибудь audit trail.
Это совсем другая подсистема, которая лишь похожа на лог.

[a-tk]

if ($user === null) { // $user является типом object
    // ...
}
if ((int)$request->postData('amount') === 100) {
    // ...
}
if ($booking->comment === '') {
    // ...
} 

А можно пояснить, откуда особый случай во втором варианте?

[misato]

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

[greabock]

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

[Invision70]

Да им PSRать

[t_kanstantsin]

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

[zojl]

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

[MKMatriX]

Всегда не любил четкие правила написания кода. Особенно обязательные. Может кто знает утилиты, позволяющие каждому разработчику видеть свое оформление, вместо того чтобы привыкать к корпоративному? Желательно так, чтобы при сохранении форматировалось в корпоративный вид, и возможно даже была подпись как переобозвать переменную для корпоративного варианта.

[abyrvalg]

Запрещены отрицательные логические названия

Почему? Меня лично раздражает выискивать глазами восклицательный знак и в уме инвертировать условие. Особенно, если надо в одном IF'е проверить пару условий.

Другое дело, если условия с отрицанием поддерживаются в самом языке:

if ($component->enabled()) { 
    print "OK"; 
}

unless ($component->enabled()) {
    print "Whoops";
}

тогда да, правило становится полезным.

[a-tk]

print "Whoops" unless $component->enabled()
Или даже так

[MikeLP]

подобное есть в Python

[a-tk]

А ещё в Perl-е и унаследовавшем эту фишку Ruby.

[Sannis]

И хорошо что в PHP этого нету.

[misato]

Если условие является большим, то обязательно выделить его в одно или несколько смысловых выражений и использовать его (их) в условии.

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

[pbatanov]

Для этого достаточно переменные заменить на методы. Сохранится и читаемость и ленивые вычисления

[misato]

Там предлагается заменять таким образом сложные условия. Весьма вероятно, что если выделить сложное условие в метод, то придётся в этот метод передать значительное количество локальных переменных, и условие всё равно будет громоздкое.

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

[misato]

Мне тоже это требование не понравилось. Я ещё понимаю, если бы это была рекомендация: «ребята не делайте так, если думаете что здесь нужны объяснения, то лучше рефакторите». Скрипты со нестандартной бизнес-логикой вообще надо документировать внутри. Любая строка, которая потенциальна похожа на ошибку, должна быть обоснована комментарием, а то потом кто-нибудь залезет и по незнанию оптимизирует. Любую какую-то формулу, какие-то условные действия — всё лучше пояснять и в идеале отсылать к задачам или документам. Комментарии — добро, а вовсе не признак плохого кода.

[brrl]

Трейты имеют постфикс Trait. Интерфейсы имеют постфикс Interface.

Вам не кажется это избыточным?

interface FooInterface {...}

trait FooTrait {...}

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

[a-tk]

Согласен, для интерфейсов вполне достаточно префикса I или суффикса -able.