Comments 62
Совет 1. Быть пхп программистом(шутка)
лучше используйте while каждый раз когда получаете данные от класса.
А чем это-то вредно? Можете рассказать чем плох такой код?
public function getResult() : \Generator
{
while ($result = $this->stmt->fetch(\PDO::FETCH_OBJ)) {
yield $result;
}
}
Тут всё просто. У вас есть 2 варианта действий:
1. Получить от модели готовый массив данных и сразу с ним работать
2. Каждый раз получать от модели ресурс и превращать его перебором в массив уже запределами модели.
Что предпочтительнее решать вам, но по-моему писать While в 1000 разных местах проекта намного лучше, чем всего 1 раз в самой модели, не правда ли? =)
1. Получить от модели готовый массив данных и сразу с ним работать
2. Каждый раз получать от модели ресурс и превращать его перебором в массив уже запределами модели.
Что предпочтительнее решать вам, но по-моему писать While в 1000 разных местах проекта намного лучше, чем всего 1 раз в самой модели, не правда ли? =)
не правда, вернее, не всегда
результаты больших выборок обрабатывать массивом неоптимально, а порой невозможно
результаты больших выборок обрабатывать массивом неоптимально, а порой невозможно
к сожалению не все так хорошо
если получили несколько записей, без разницы в массиве или в ресурсе то цикл все равно придется делать по записям (вы же не просто так список получили) и большой разницы по ресурсу или по массиву нет.
Плюсы ресурса
В некоторых базах ресурс это указатель на данные, которые на стороне БД это значит что в память application сервера они не загруженны.
В случае если цикл по ресурсу и вы точно знаете что данные потом не пригодятся вы можете после извлечения( fetch) эту переменную освободить и тем самым обрабатывать огромное количество данных, не грузя их единовременно в память application сервера.
Но да ситуации возникают крайне редко и в большинстве случаев удобней иметь именно массив.
если получили несколько записей, без разницы в массиве или в ресурсе то цикл все равно придется делать по записям (вы же не просто так список получили) и большой разницы по ресурсу или по массиву нет.
Плюсы ресурса
В некоторых базах ресурс это указатель на данные, которые на стороне БД это значит что в память application сервера они не загруженны.
В случае если цикл по ресурсу и вы точно знаете что данные потом не пригодятся вы можете после извлечения( fetch) эту переменную освободить и тем самым обрабатывать огромное количество данных, не грузя их единовременно в память application сервера.
Но да ситуации возникают крайне редко и в большинстве случаев удобней иметь именно массив.
Подключайте все файлы проекта в любом месте проекта даже если вам нужна всего одна функция.
Ну вряд ли кто-то вручную подключает все файлы.
А стоит ли использовать тяжеловесные фреймворки? :)
Используйте массив GLOBALS — без него вообще никак, разработчики языка придумали его для вашего удобства, а вот проблемы с закончившейся озушкой это проблемы сервера, а не языка.
Разве GLOBALS страшны закончившейся озушкой. Я такого не слышал :)
используйте циклы прямо в верстке
Хм, а как вывести список по другому? :)
Дублируйте один и тот же метод во всех классах каждый раз, когда он вам понадобится, забудьте про наследование это пережиток прошлого.
Лучше просто использовать метод/ф-ю без наследования.
Используйте только статические методы и свойства, не нужно создавать объекты, классы придуманы не для этого.
Когда существует только один инстанс/нету привязки у метода к инстансу, то часто так и делаю :)
выключите error_reporting — он только мешает
На проде выключил E_NOTICE
display_errors само собой
Храните всю информацию о пользователях в одной таблице — данные для авторизации, анкетные данные, домашние адреса и телефоны, места работы, да вообще любую информацию храните в одной таблице и не забывайте про serialize
Часто требования на старте одни, а потом другие, или вообще требования не формализированы. :)
В postgres можно нативно хранить массивы.
А иногда нужна денормализация. :)
В postgres можно нативно хранить массивы.
В MySQL тоже относительно недавно добавили тип JSON.
Это чуть другое.
Ну и они не индексируются.
Но как вариант.
Хотя и раньше можно было сохранять JSON данные.
Ну и они не индексируются.
Но как вариант.
Хотя и раньше можно было сохранять JSON данные.
Конечно, я в первую очередь о том, что время идет, и функции добавляются (я был даже удивлен, что добавили JSON, так как наткнулся об этом чуть ли не случайно). Сначала, конечно, многого не хватает, но потом сделают определенные оптимизации и т.д., может еще со временем и добавят нужное.
Да и если подумать навскидку, мне кажется сомнительным индексировать по JSON, лучше уж тогда создать несколько дополнительных полей.
Да и если подумать навскидку, мне кажется сомнительным индексировать по JSON, лучше уж тогда создать несколько дополнительных полей.
> 29.Для того чтобы получить по-настоящему большой класс, нужно для каждой скобочки выделять целую строчку
Именно так советует PSR
Именно так советует PSR
29a. Но самое главное — разнообразие стилей. Будьте оригинальны!
class MyClass {
public function f()
{
if (a == b)
{
..
}
}
}
UFO just landed and posted this here
А я где то писал, что после каждой? Внимательнее читайте комментарий
Строго говоря вы опрвергали автора, используя его цитату, где он говорил именно про каждую скобочку.
Но в ваше оправдание отмечу, что мысль про PSR была ясна каждому (почти), учитывая простоту и очевидность рекомендации, а замечание от OnYourLips подозреваю, всего лишь придирки.
31. Забудьте про PSR и Code-style. У каждого Senior PHP-программиста должен быть свой стиль. И вообщем у всех в команде должен быть свой стайл, не нужно быть подражалой.
блин, лучше не комментировать статьи про php и apple. Всегда крайне неожиданная реакция… то в плюс, то в минус :)
PSR являются рекомендациями. Им можно следовать, а можно и не следовать.
К сожалению да, это лишь рекомендации, которым мало кто следует. В php-мире вообще мало кто чему-то следует, потому что нафиг надо учить еще какие-то рекомендации, шаблоны, бест практикс и прочее, ведь php нам позволяет всё фигачить, как угодно и не заморачиваться об этом. Да и поддержкой проектов не нужно заморачиваться — отстрочил сайтик за большие деньги, впарил его заказчику, а дальше пусть сам с ним парится.
Печальная правда жизни, только за что мне-то теперь минус лепить? Не я же таким php сделал :)
Печальная правда жизни, только за что мне-то теперь минус лепить? Не я же таким php сделал :)
Мало кто? о_0 Я что-то не припомню популярного framework-agnostic (ну или зенд, симфони, лара...) кода пакета, который бы не следовал первым 4ём PSR.
Нормально Вы загнули :)
Я поэтому и пишу на симфони, потому что там хоть люди следуют этому и понимают важность этого.
Но в php это лишь мельчайшая часть от всего пирога.
Назовите лучше CMS, которая этому следует.
А тестами удобно покрывать приложения на yii? Вот честно, все кричат, что это легко делается, но постоянно вижу, что через пол года все на них забивают :) Да, конечно, заказчик против. Да просто там их писать намного сложнее, чем на том же симфони. И дело не в самих тестах, а в том, что просто ими покрывать код сложнее, ведь нафиг нам эти абстракции, мы от них отошли и налепили всё в кучу. DI в yii никакой, компоненты тестируются сложно, получение хоть чего из любой части кода тоже добавляет веселья к тестированию.
Ладно, простите, разошелся… Это же php, тут так принято и так все привыкли. Не стоит переусложнять.
Только не говорите — «Все? о_0 У нас все пишут слабосвязанный код, который легко поддается тестированию, локализации, валидации и прочему-прочему». Не верю!
На php это делать очень и очень сложно. Сам язык постоянно толкает на «схалтурить», и я не исключение. А те библиотеки, CMS, фреймворки и прочее является лишь логическим продолжением такого подхода.
Хотя Symfony 2+ реально задает тон для приложений, требующих серьезной долгосрочной поддержки, но его используют реально единицы даже серьезных проектов и компаний… ведь он таак слооожен, там же нужно столько шаблонов знать и думать, прежде чем код написать… не, нафиг, лучше возьмем yii, там можно халтурить, как и в остальном php :)
Хотя может, конечно, мир изменился, потому что я около 2х лет пытаюсь избегать в php CMS, самописных велосипедов, kohana, cake и т.п. Жаль, что редко это получается.
С ларавелем близко не сталкивался.
Я поэтому и пишу на симфони, потому что там хоть люди следуют этому и понимают важность этого.
Но в php это лишь мельчайшая часть от всего пирога.
Назовите лучше CMS, которая этому следует.
А тестами удобно покрывать приложения на yii? Вот честно, все кричат, что это легко делается, но постоянно вижу, что через пол года все на них забивают :) Да, конечно, заказчик против. Да просто там их писать намного сложнее, чем на том же симфони. И дело не в самих тестах, а в том, что просто ими покрывать код сложнее, ведь нафиг нам эти абстракции, мы от них отошли и налепили всё в кучу. DI в yii никакой, компоненты тестируются сложно, получение хоть чего из любой части кода тоже добавляет веселья к тестированию.
Ладно, простите, разошелся… Это же php, тут так принято и так все привыкли. Не стоит переусложнять.
Только не говорите — «Все? о_0 У нас все пишут слабосвязанный код, который легко поддается тестированию, локализации, валидации и прочему-прочему». Не верю!
На php это делать очень и очень сложно. Сам язык постоянно толкает на «схалтурить», и я не исключение. А те библиотеки, CMS, фреймворки и прочее является лишь логическим продолжением такого подхода.
Хотя Symfony 2+ реально задает тон для приложений, требующих серьезной долгосрочной поддержки, но его используют реально единицы даже серьезных проектов и компаний… ведь он таак слооожен, там же нужно столько шаблонов знать и думать, прежде чем код написать… не, нафиг, лучше возьмем yii, там можно халтурить, как и в остальном php :)
Хотя может, конечно, мир изменился, потому что я около 2х лет пытаюсь избегать в php CMS, самописных велосипедов, kohana, cake и т.п. Жаль, что редко это получается.
С ларавелем близко не сталкивался.
> Назовите лучше CMS, которая этому следует.
Можете посмотреть мою:
https://github.com/litepubl/cms
Не идеал, и если есть желание найти недостатки, то не сомневайтесь — они там есть. Штука в том, что нужно уметь выкрутиться не наплодив лишних сущностей. Впрочем это тема для отдельной большой статьи
Можете посмотреть мою:
https://github.com/litepubl/cms
Не идеал, и если есть желание найти недостатки, то не сомневайтесь — они там есть. Штука в том, что нужно уметь выкрутиться не наплодив лишних сущностей. Впрочем это тема для отдельной большой статьи
А тестами удобно покрывать приложения на yii?
^ Yii2, полгода проекту, функционал развивается, тесты пишутся, как unit, так и functional, всё очень даже удобно.
Что Вы пишете? То про делфи, то про это.
Я говорю общую картину и объективные вещи, вы говорите какие-то узко-субъективные вещи.
Я тоже могу напрячься и написать тестируемый код на yii, но разговор про то, что это делать очень сложно, если работал с гораздо более удобными подходами.
Когда-то мне нравилось делать сайты на wordpress. Это реально мне казалось очень удобно и классно. Потом попробовал другое и стал постоянно плеваться от вордпресса. Сейчас просто попробовал еще что-то вкуснее, чем yii2, да и вкуснее, чем php :)
Я говорю общую картину и объективные вещи, вы говорите какие-то узко-субъективные вещи.
Я тоже могу напрячься и написать тестируемый код на yii, но разговор про то, что это делать очень сложно, если работал с гораздо более удобными подходами.
Когда-то мне нравилось делать сайты на wordpress. Это реально мне казалось очень удобно и классно. Потом попробовал другое и стал постоянно плеваться от вордпресса. Сейчас просто попробовал еще что-то вкуснее, чем yii2, да и вкуснее, чем php :)
Про Delphi и про тестирование Yii2 я написал к тому, что не зная, не желая, не напрягаясь, делая на "отстань" можно действительно всегда делать откровенную хрень.
С другой стороны, если всё же напрячься (или вы считаете, что программист не должен напрягаться?), то можно из того и из другого извлечь множество профита. Ваше нежелание напрягаться и постоянный поиск новых инструментов, которые позволят меньше напрягаться («перешёл на Go, там же есть go fmt!!!!11») не означает, что те инструменты, в которых вы так и не разобрались, являются плохими.
С другой стороны, если всё же напрячься (или вы считаете, что программист не должен напрягаться?), то можно из того и из другого извлечь множество профита. Ваше нежелание напрягаться и постоянный поиск новых инструментов, которые позволят меньше напрягаться («перешёл на Go, там же есть go fmt!!!!11») не означает, что те инструменты, в которых вы так и не разобрались, являются плохими.
Я прекрасно знаю все кишки yii и первого, и второго. И написал на нем несколько крупных приложений. И работал в проектах, которые не я начинал писать. И также в проектах, где работает 2-4 программиста, а также где 20+ программистов. Это про «неразобравшись».
Про разные модные словечки, типа Go или Scala, это тема другого разговора.
Я считаю, что программист не должен напрягаться над написанием кода, он должен напрягаться над логикой приложения, его архитектурой(не в глобальном смысле) и над решением бизнес-задач.
Хочется много всего еще сказать, как в целом, так и про yii в частности, но пора бы и пойти поработать :)
Про разные модные словечки, типа Go или Scala, это тема другого разговора.
Я считаю, что программист не должен напрягаться над написанием кода, он должен напрягаться над логикой приложения, его архитектурой(не в глобальном смысле) и над решением бизнес-задач.
Хочется много всего еще сказать, как в целом, так и про yii в частности, но пора бы и пойти поработать :)
Думаю, есть разница между фреймворками и между продакшн кодом. Там все до сих пор бывает печально.
Хотя, о чем уже говорить, какой к черту PSR, мне если не нравится форматирование, есть автоформатировщики в IDE, которые приведут код к одному образцу. Меня больше волнует то, что я до сих пор часто прямое использование mysql_* функций…
Это хорошо, когда есть время отрефакторить, а иногда заказчику трудно объяснить, почему этот код плохой, если до сих пор рабочий…
Хотя, о чем уже говорить, какой к черту PSR, мне если не нравится форматирование, есть автоформатировщики в IDE, которые приведут код к одному образцу. Меня больше волнует то, что я до сих пор часто прямое использование mysql_* функций…
Это хорошо, когда есть время отрефакторить, а иногда заказчику трудно объяснить, почему этот код плохой, если до сих пор рабочий…
На Delphi тоже можно писать красиво и я даже это практиковал.
UFO just landed and posted this here
Перегибаете.
Пожалуй это одна из лучших статей по PHP из песочницы за последнее время.
Добро пожаловать на хабр!
Ого-го, целых 12 любителей тех замечательных статей из песочницы "как я делал свой велосипед на костылях и процедурном стиле в 2016 году". Это со мной что-то не так или же ...?
UFO just landed and posted this here
Я видел достаточно не «начинающих» разработчиков, которые на полном серьёзе считают, что хранить в базе сериализованые нативными средствами классы (да, именно классы, а не мапы) — хорошая идея, ещё и через `LIKE` умудряются по ним искать, да и в целом к БД почти у всех разработчиков достаточно наплевательское отношение. Есть ещё особая секта разработчиков — «мастера оптимизации», которые экономят на «скорости обработки типов строк» (т.е. давний холивар на тему `"` vs `'`) при этом используя тяжеловесные ORM, записывая в одну и ту же переменную разные типы, проходя один и тот же массив по 20 раз в разных местах ничего не меняя в промежутках и т.д.
Так что я действительно считаю, что это достойная статья (хоть может и публикация в пятничный вечер была бы более к месту). Особенно, как я уже подметил, на фоне остальных. И я правда искренне удивлён минусам как к своим комментариям, так и к статье.
P.S. Вот так вот неудачно оставишь благодарность и уже не сможешь использовать разметку в комментариях :( Так что уж извиняйте за голый markdown.
Так что я действительно считаю, что это достойная статья (хоть может и публикация в пятничный вечер была бы более к месту). Особенно, как я уже подметил, на фоне остальных. И я правда искренне удивлён минусам как к своим комментариям, так и к статье.
P.S. Вот так вот неудачно оставишь благодарность и уже не сможешь использовать разметку в комментариях :( Так что уж извиняйте за голый markdown.
Нет, просто статья так себе. Часть пунктов уровня «не суйте пальцы в розетку», по части есть желание услышать обоснования или поспорить.
Что-то вообще не смешно. Автор, судя по всему, с 2004 по 2016 провёл в летаргическом сне
31. Упаковывайте сложные выражения и проверки в одну строку, желательно вместе с объявлением переменной в условии:
if ($tru=($a==$b & $b==$c & $c+$d>$e?$f:$g)) {
$this->do($tru);
}
Уважаемые профессионалы подскажите как правильно делать верстку чтобы не получилось как в 1 и 2?
Можно пример небольшого проекта как правильно верстать?
Можно пример небольшого проекта как правильно верстать?
16. Не создавайте много ячеек в таблицах БД, лучше используйте seialize и забудьте про кодировку при сохранении, если unserialize каждый раз выдает ошибку, просто игнорируйте её.
21. Храните всю информацию о пользователях в одной таблице — данные для авторизации, анкетные данные, домашние адреса и телефоны, места работы, да вообще любую информацию храните в одной таблице и не забывайте про serialize
23. Никогда не используйте таблицы-справочники, лучше дублируйте все в одной колонке, тем более если колонка содержит большие и часто повторяющиеся данные.
Это уже архитектура БД. Тут уже всё зависит от задачи. Когда речь заходит о высоких нагрузках, то появление избыточности — нормально.
Также, почему serialize-то? JSON — и всё, мы не зависим от версий PHP.
19. Пишите только так for($i=0; $i<count($arr); $i++), потому-что считать количество элементов в массиве при каждой итерации это хорошо, а постинкремент работает намного быстрее, а кто говорит наоборот просто не знает о чем говорит. И перебирать большой массив нужно именно сначала, потому-что так быстрее.
Постинкремент оптимизатором PHP уже умеет переделываться в преинкремент, так что это дело исключительно визуального удобства. Массивы же в PHP5+ хранят длину в себе, так что вынести можно и это будет в любом случае лучше, но не так критично, как описано тут.
26. Никогда и нигде не пишите комментарии, потому-что тру-прогерам они не нужны, в худшем случае можно написать коммент типа /*это функция a(), она принимает две переменные $a и $b*/ для совсем тупых.
Вообще давняя отдельная дискуссия про наличие комментариев и их объем.
29. Для того чтобы получить по-настоящему большой класс, нужно для каждой скобочки выделять целую строчку
psr-2
Серега, даже не знаю поздравить тебя или посочувствовать. Инвайт ты таки получил но карму тебе сразу слили.
У него legacy проект где нет composer и из за кучей инклюдов в разных файлах он долго пытался понять где и что подключается.
В том проекте храниться в них все, начиная от результатов выборки бд на более 1ккк строк, заканчивая данными из сессий пользователей.
Тут мы постоянно спорим IRL — автор сразу создает DOM объект и рендерит уже чистый html добавляя в него данные списка. Я же юзаю laravel и использую конструкции for в blade
В этом случае все ок, но когда все начиная от моделей и заканчивая шаблонами и бизнес-логикой сделано статикой, это превращается в ад.
В проекте автора есть три таблицы на +100 полей причем в них есть 3-5 поля с php serialize на еще +50 полей. Причем некоторые serialize были поправлены без десериализации чьими-то кривыми ручками в базе и окончательно испорчены.
Ну вряд ли кто-то вручную подключает все файлы.
А стоит ли использовать тяжеловесные фреймворки? :)
У него legacy проект где нет composer и из за кучей инклюдов в разных файлах он долго пытался понять где и что подключается.
Разве GLOBALS страшны закончившейся озушкой. Я такого не слышал :)
В том проекте храниться в них все, начиная от результатов выборки бд на более 1ккк строк, заканчивая данными из сессий пользователей.
Хм, а как вывести список по другому? :)
Тут мы постоянно спорим IRL — автор сразу создает DOM объект и рендерит уже чистый html добавляя в него данные списка. Я же юзаю laravel и использую конструкции for в blade
Когда существует только один инстанс/нету привязки у метода к инстансу, то часто так и делаю :)
В этом случае все ок, но когда все начиная от моделей и заканчивая шаблонами и бизнес-логикой сделано статикой, это превращается в ад.
Храните всю информацию о пользователях в одной таблице — данные для авторизации, анкетные данные, домашние адреса и телефоны, места работы, да вообще любую информацию храните в одной таблице и не забывайте про serialize
В проекте автора есть три таблицы на +100 полей причем в них есть 3-5 поля с php serialize на еще +50 полей. Причем некоторые serialize были поправлены без десериализации чьими-то кривыми ручками в базе и окончательно испорчены.
Достаточно, в одном файле весь проект сделать.
Эта шутка была актуальна где то 5 — 7 лет назад
Интересно, когда уже программисты примут тот факт что count/sizeof не считает элементы массива, а на прямую обращается к данным о его размере.
Устал читать глупости про «не используйте count в циклах».
Устал читать глупости про «не используйте count в циклах».
Странные «вредные» советы. Похоже автору очень импонирует собственный, авторский, стиль написания кода. Любой другой стиль автоматически становится сборником неких вредных правил :) Добрее надо быть :)
P.S. Особенно порадовал пункт про скобочки.
P.S. Особенно порадовал пункт про скобочки.
UPD
Публикация внезапно набрала отрицательный рейтинг
От G-M-A-X
1. Если что, то я не могу минусовать… :)
2. Зачем мне сдалить E_NOTICE на проде? На деве — пожалуйста. :) А тем более с выводом на экран.
Ждем вторую часть с полезными советами и примерами, я вот не кодер но пишу что то для себя и было бы интересно перенять опыт хороший!
Sign up to leave a comment.
30 вредных советов для php-разработчиков