Комментарии 51
Мы думали над этим, не против запилить, но дело не простое и уж точно не приоритетное.
ИМХО это будет или прогнуться под чужой стандарт или тащить с собой кучу подсистем.
И это помимо того что надо отдирать связность с ядром, хелперами, DI и т.п.
А всё это без заметного изменения АПИ сделать будет едва ли возможно.
Признаться в коде Yii особо не копался, но по опыту кажется что будет ахтунг.
У логеров хоть стандарт есть (PSR-3) и то работа будет не то чтобы элементарная.
Независимые компоненты — штука хорошая, но у независимости есть цена. Приходится отказываться от переиспользования кода из ядра фреймворка, что выливается в довольно большой объём кода как такового и, зачастую, переабстрагированные решения.
А кто мешает ядро сделать тоже независимым компонентом? И переиспользовать его как угодно. В итоге получится эдакий шаг в сторону Zend Framework или Symfony.
Я ни в коем случае не агитирую немедленно так и поступить, Yii его монолитность даже на пользу, просто изначальное утверждение довольно спорное.
Смотря что подразумевать под ядром. Тот же роутер сейчас — ядро, обработка ошибок — тоже.
По логике — ядро = нечто неделимое, некая базовая единица функциональности (ядерную физику в расчет не берем). Роутер, по-идее — это уже не совсем ядро, приложение же может выжить без него, если оно консольное. А вот обработка ошибок — вполне.
В любом случае тут стоит подойти творчески и сбалансировать гранулярность, например, по принципам high cohesion и single responsibility (и другим подобным), чтобы вещи одной предметной области были в одном модуле, но без фанатизма, чтоб не пихать все подряд.
Если гранулярность довести до абсолюта, то получаются NPM пакеты isNumber
и так далее ;) а если наоборот — то Yii Framework.
А вот обработка ошибок — вполне.
Но это не вяжется с вытаскиванием библиотек. Потому что там, где их могут в теории использовать, своя обработка ошибок.
Если гранулярность довести до абсолюта, то получаются NPM пакеты isNumber
и так далее ;) а если наоборот — то Yii Framework.
Ну не :) У нас всё-таки много уже разделено, просто основной пакет жирный и дополнительные вроде Redis зависят от него.
Но вот что делать с хардкорными зависимостями вроде завязки на DI, базовые классы тех же компонент, всякие ArrayHelper и прочие специфичные вещи? Ну если хелперы и прочее еще можно вынести в отдельные пакеты которые потом в зависимости засунуть, то что делать с самым ядерным API? Это переписывание всей архитектуры. Совсем всей. И да, увеличение объема кода как цена минимальной связности. Иначе если просто разобрать на части и прописать зависимости, то композер нам весь фреймворк и притянет.
На дворе 2017-ый год и довольно значительная часть сообщества PHP пытается использовать
PSR: PHP standard recommendation, цель которых — дать возможность заменять отдельные части фреймворков.
Александр, я думаю, скорее всё дело в том, что вы участвуете в FIG, и у вас такое мнение из-за того, что этот котёл является частью вашей жизни.
Насколько я вижу из своего личного общения и из мыслей людей (а я всегда очень много и внимательно читаю чужое мнение на различных околопхпэшных ресурсах), люди начинают уставать от PSR из-за того, что стандарты PSR определяются один раз, и они развивают промышленность только в первое время. Однако, из-за подхода: «мы не будем ничего менять, потому что мы пять лет назад проголосовали за такой вариант (не будем вообще больше голосовать на эту тему)» — через какое-то время PSR начинает тормозить всё, а не помогать строить светлое будущее.
PSR, как бы, первое время помогает стать лучше, а потом, когда в PHP появляются какие-то изменения, PSR превращается в гирю на ноге, вместо того, чтобы быть двигателем.
Помню свой личный кейс, когда я ворчал по шорттегам, мол <?php прошлый век.
И СамДарк как раз мне и ответил что позиция тут в том, что <? всё еще можно отключить.
В принципе логично.
Опять таки — большинство стандартов это чисто стилистика, и определялась по принципу что выберем то и будет. Менять ее сейчас? Смысл? PSR созданы в первую очередь для единообразия.
Допускаю что я что-то пропустил, или вы говорите о тех стандартах которые не самые популярные, но хотелось бы примеров.
PSR созданы в первую очередь для единообразия
Как раз с единообразием есть кейс: Фигурные скобки в классах и функциях. До того, как в PHP появились анонимные классы и функции, фигурные скобки можно было нормально писать на следующей строке во всех ситуациях. Теперь же получается, что в определении класса в одной ситуации нужно писать их на той же строке, а в другой — на новой строке. Единообразие в подходе потрялось.
С одной стороны, люди понимают, что если эти скобки писать в анонимных классах и функциях с новой строки, уродуется код. Но вместо того, чтобы сделать единый подход, поменяв вообще стиль для любых классов и функций, сделали патч, который меняет подход в отдельных случаях, хотя можно было одним изменением решить эту проблему системно.
Если кто-то предлагает базовые вещи менять в стандарте, его отфутболивают (меня лично не отфутболивали, я просто уже долго наблюдаю за тем, как происходят обсуждения в FIG).
Большинство изначально использовало такой стиль, именно поэтому такой стиль используется в стандарте, а не наоборот.
Ну и вряд ли coding style можно назвать чем-то, что мешает "строить светлое будущее" :)
Если бы была возможность выяснить, как пишет большинство разработчкив, ещё неизвестно, что было бы в стандарте, потому что я чаще видел код, в котором фигурные скобки были на той же строке. Ну, просто, такой чаще встречался, чем код, где скобки шли на новой строке. Может быть, мне просто чаще такой код попадался, а на самом деле больше было кода, где скобки шли с новой строки. Лично я видел такую картину.
Не всенародное, но голосование было (не путать с голосовавшими за стандарт):
http://www.php-fig.org/psr/psr-2/#appendix-a-survey
https://docs.google.com/spreadsheets/d/1b-wBdRi4j9bQWLi91r8hUMUoydQFA1LSmBbez1L4dVM/edit#gid=0
Вы писали, что «большинство изначально использовало такой стиль». Я с этим не согласен. Половина использовала один стиль, другая половина – другой. 50–100 разработчиков в крупных проектах — это не большинство программистов на тот момент.
Ее и сейчас не хватает, но раньше это кошмар был…
90% и сейчас говнокодеры, и их мнение по СТИЛЮ вообще не интересны.
Если мы сейчас начнем спрашивать стиль у всех, то мы получим смесь вордпрессовского кодекса с VQMOD (простите что помянул к ночи).
Вы хотите спрашивать мнение у людей использующих VQMOD? Вы хотите спрашивать мнение у людей которые способны использовать VQMOD? Вы хотите спрашивать мнение по стандартам оформления кода у людей которые знают что это такое, имели дело с VQMOD и способны говорить об этом без мата? Вы уверены?)
А ведь 90% сайтов, включая магазины сейчас делают на таких вещах или подобных вещах.
Вы не знаете что это и как оно работает?
Почитайте.
Там еще примеры есть, а то подозреваю без них многие решат что неправильно поняли что это и зачем).
Только на ночь не читайте.
И да, это не времена когда ООП в пхп был неработоспособным.
Вполне себе используется вместе с классами, даже «MVC».)))
И ведь это не пять строчек кода. Это кто-то соорудил, отладил, сотни разных модулей существуют работающих на этом идиотизме. Этот кошмар на гитхабе лежит, т.е. этот с позволения сказать «разработчик» даже гит использует. И да, у него есть какой-то стандарт кодирования. Его код даже можно читать. Мой код семилетней давности который до сих пор работает в некоторых проектах мне самому было читать много сложнее. Спросим у него как лучше оформлять код?)) Как именовать переменные, по сколько строк можно методы делать? Мне например тоже чисто визуально его оформление приятнее. Привычнее чтоли со времен когда я еще с пхп дела не имел. Но… может не надо?)
Даже на выборах голосуют только дееспособные.
Причем по определенным ФОРМАЛЬНЫМ критериям.
Никому не проводят тесть Тьюринга на избирательном участке. (а жаль).
Возраст подходит? Справки о недееспособности нет? Пришел? Голосуй.
Так и здесь. Можешь участвовать в большом проекте? Пришел? Тебя посчитали).
Проголосовало «квалифицированное большинство». Не в том смысле в каком это словосочетание используют, а в значении дискриминации неквалифицированных)
Вот кстати статистика за 2013-2014 года. Думаю она актуальная в контексте нашей дискуссии. За это время PSR-2 не успел сильно распространиться
Но вы же писали, что большинство так писало
Речь шла о "значимых" проектах, чьи участники принимали участие в формировании стандарта.
я нигде не утверждал, что нужно было спрашивать большинство. Я только озвучил факт, что всенародного голосования не было, и стиль брали из самых известных проектов, что на тот момент давало FIG политические очки.
И что тогда вы хотели этим сказать? :)
Речь шла о «значимых» проектах, чьи участники принимали участие в формировании стандарта.
Если речь шла о значимых проектах, для чего вы кидали ссылку на http://sideeffect.kr/popularconvention#php в подтверждение ваших слов про «большинство»?
И что тогда вы хотели этим сказать? :)
Я хотел сказать, что из-за невнимательности люди начинают оспаривать слова, которые я не говорил. И этим тратят моё время впустую.
На момент появления PSR-2 эти 22 проекта занимали крупную нишу во всех ±600 миллионах сайтов под PHP. Однако, если брать отдельных людей, которые в тот момент писали на PHP, их будет больше, чем количество людей, которые трудились над этими 22-мя проектами.
Понимаете мысль?
Одни PSR способны заменять другие, как это произошло с PSR-0 и PSR-4 и как это, скорее всего, произойдёт с PSR-1, PSR-2 и PSR-12.
Случая всего два:
- Не анонимные классы и функции — следующая строка.
- Анонимные классы и функции — та же строка.
Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.
Случая всего два
А мог бы быть один: «всегда та же строка». И это было бы проще, и было бы единообразие.
Кто пишет анонимки с открывающей скобкой на следующей строке — поднимите руки.
Добавьте это в стандарт и потихоньку все начнут писать так. Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
Будет выглядеть некрасиво из-за контекста, в котором они обычно используются, но всё равно люди будут подтягиваться к стандарту.
Вы путаете с единообразием
PSR-12 не упрощает вещи, хотя мог бы.
Сделать стандартным правило расстановки скобок ≠ упростить. Текущая реализация вполне логична и делает проще чтение и изменение кода.
Логические конструкции и анонимные функции — на одной строке, чтобы код не разрастался по вертикали и его было удобнее читать.
Функции и классы — на новой строке, чтобы их описание не сливалось с кодом, что, опять же, упрощает чтение.
В случае с классами на одной строке с названием могут быть extends
и implements
, которые удобнее добавлять в конце строке, а не кликать перед символом фигурной скобки.
И все-таки это ну никак не "архитектурная" проблема и, судя по приведенным вами примерам — единственная. Поэтому утверждение, что "через какое-то время PSR начинает тормозить всё, а не помогать строить светлое будущее" немного преувеличено :)
Вы путаете с единообразием
Если не сложно, поясните, что именно я путаю с единообразием? Я не совсем понял. Я путаю «выглядеть некрасиво», или я путаю «к стандарту», или что-то ещё?
И все-таки это ну никак не «архитектурная» проблема
Мне кажется, она похожа на архитектурную проблему. Всё-таки эта проблема касается совокупности факторов. Если бы речь шла просто о том, что нужно или не нужно ставить скобки на отдельной строке, это была бы не архитектурная проблема. Но раз речь идёт о том, что можно единообразно относиться к похожим явлениям, и это единообразие поможет избавиться от избыточных описаний в стандарте, то это больше похоже на архитектурную проблему.
Исторически так сложилось. Вот как освою скрипты которые за меня оформление править будут, да доведу свой фреймворк до RC1 (точнее сначала доведу), тогда может начну переучиваться.
Так что да, если бы 12 делал бы на той же строке, то мне было бы удобно.
Но нет, я бы не проголосовал за такое изменение.
Пусть лучше гады переучиваются (и я в том числе), чем скакать туда-сюда.
Ведь в любом случае кто-то будет переучиваться. Или я, или тот парень, который уже научился под PSR.
When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them.
Так что, случаев больше получается, чем два. А ведь можно было бы всё упростить, если, хотя бы для методов/функций, открывающая фигурная скобка писалась всегда на той же самой строке. Кучу «лишнего кода» ведь можно было бы тогда выкинуть из текста. :)
Это описание стандарта. Важно чтобы при его прочтении не возникло недопонимания, поэтому текст бы никуда не делся, а просто заменили бы фразы "на следующей строке" \ "на этой же строке" на противоположные и все :)
http://www.php-fig.org/psr/psr-2/#overview
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
На лицо дублирование, но почему-то никто не объединил эти два пункта ;)
Один пункт — одно утверждение
Логирование в Yii 2.0 и PSR-3