How to become an author
Search
Write a publication
Pull to refresh

Comments 29

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

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

P.S. Хабр упорно перемещает мой комментарий не в ту ветку, написал в саппорт.
Total votes 5: ↑4 and ↓1+3

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


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


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

Total votes 5: ↑1 and ↓4-3
PSR — всего лишь рекомендации — вы не обязаны их соблюдать.
GRASP — всего лишь шаблны — вы не обязаны их использовать.
SOLID — всего лишь принципы — вам не обязательно им следовать.

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

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

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

А я не про законы, я про практическую ценность конкретных ограничений.
This comment wasn’t rated yet0

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


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

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


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

Total votes 2: ↑2 and ↓0+2
Даже если это в легаси, надо покарать того, кто это наследие оставил.
This comment wasn’t rated yet0
Легаси разное бывает, иногда такое древнее, что и карать как бы и не за что. В те времена, когда охотились на мамонтов, так было принято.
This comment wasn’t rated yet0
И да, если ваш логгер бросает исключения, которые (внезапно!) должны логироваться, то честное слово — у вас проблемы побольше чем выразительность PSR. И, пожалуй, я могу понять если это легаси, с которым приходится жить. Но в новых проектах так делать нельзя.

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

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

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

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

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

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

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


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


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


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


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


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


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

This comment wasn’t rated yet0
Что не так с требованиями бизнеса не проводить операцию при невозможности записать лог?

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

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

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

Total votes 11: ↑8 and ↓3+5

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

This comment wasn’t rated yet0
Разных code-conventions много, но такие, где были бы еще и аргументы по каждому требованию — это редкость. А предложенное в статье выделяется из общей массы лишь тем, что местами противоречит PSR. Возникает очень много «почему» практически по каждому пункту.
Total votes 2: ↑2 and ↓0+2
Всегда не любил четкие правила написания кода. Особенно обязательные. Может кто знает утилиты, позволяющие каждому разработчику видеть свое оформление, вместо того чтобы привыкать к корпоративному? Желательно так, чтобы при сохранении форматировалось в корпоративный вид, и возможно даже была подпись как переобозвать переменную для корпоративного варианта.
Total votes 2: ↑1 and ↓10
Запрещены отрицательные логические названия
Почему? Меня лично раздражает выискивать глазами восклицательный знак и в уме инвертировать условие. Особенно, если надо в одном IF'е проверить пару условий.

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

unless ($component->enabled()) {
    print "Whoops";
}
тогда да, правило становится полезным.
Total votes 1: ↑0 and ↓1-1
print "Whoops" unless $component->enabled()
Или даже так
This comment wasn’t rated yet0
подобное есть в Python
This comment wasn’t rated yet0
А ещё в Perl-е и унаследовавшем эту фишку Ruby.
This comment wasn’t rated yet0

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

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

В приведённом «хорошем» примере всегда будут вычисляться все три условия, тогда как в «плохом» достаточно одного, принимающего значение false. Мелочь, но иногда может сыграть. Думаю, такое вообще не должно относиться к стилю кода.
Total votes 2: ↑2 and ↓0+2
Для этого достаточно переменные заменить на методы. Сохранится и читаемость и ленивые вычисления
This comment wasn’t rated yet0
Там предлагается заменять таким образом сложные условия. Весьма вероятно, что если выделить сложное условие в метод, то придётся в этот метод передать значительное количество локальных переменных, и условие всё равно будет громоздкое.

Вот то, как это приведено в примере — это неплохое решение для кода, реализующего запутанную, не очень интуитивную бизнес-логику. Я и сам так делал, когда каждое из условий вычисляется относительно легко, читаемость просто супер. Просто делать так или нет — зависит от конкретной ситуации, а в этом code style это указано как требование, что не очень хорошо, на мой взгляд.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
Мне тоже это требование не понравилось. Я ещё понимаю, если бы это была рекомендация: «ребята не делайте так, если думаете что здесь нужны объяснения, то лучше рефакторите». Скрипты со нестандартной бизнес-логикой вообще надо документировать внутри. Любая строка, которая потенциальна похожа на ошибку, должна быть обоснована комментарием, а то потом кто-нибудь залезет и по незнанию оптимизирует. Любую какую-то формулу, какие-то условные действия — всё лучше пояснять и в идеале отсылать к задачам или документам. Комментарии — добро, а вовсе не признак плохого кода.
Total votes 1: ↑1 and ↓0+1
Трейты имеют постфикс Trait. Интерфейсы имеют постфикс Interface.

Вам не кажется это избыточным?
interface FooInterface {...}

trait FooTrait {...}


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

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

This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr