Итак поехали:
- Обязательно пишите вёрстку прямо в php-скриптах и выводите её только через echo (зачем-то же нужна эта конструкция языка).
- Старайтесь использовать как можно больше echo в ваших проектах, помните, что её придумали крутые разработчики языка, до которых вам далеко.
- Прописывайте параметры подключения к БД в каждом файле где это нужно, и нигде не храните инфу о том где и какие конфигурации прописаны — пусть все остальные развиваются до вашего уровня.
- Создавайте как можно больше подключений к БД в разных частях проекта, желательно чтобы многие из них вызывались одновременно, вообще создавайте новое подключение к БД при каждом запуске любой функции.
- Не используйте стандартные функции языка — пишите свои, они будут работать в 100 раз лучше и именно так, как вам нужно.
- Подключайте все файлы проекта в любом месте проекта даже если вам нужна всего одна функция.
- Используйте массив GLOBALS — без него вообще никак, разработчики языка придумали его для вашего удобства, а вот проблемы с закончившейся озушкой это проблемы сервера, а не языка.
- Вызывайте функции и используйте циклы прямо в верстке, это вывод информации, там без функций никак.
- Ни в коем случае не используйте mysql-параметры, пишите переменные $_GET, $_POST, прямо в запрос, чтобы не тратить лишнее процессорное время, оно для нас очень важно.
- Дублируйте один и тот же метод во всех классах каждый раз, когда он вам понадобится, забудьте про наследование это пережиток прошлого.
- Используйте только статические методы и свойства, не нужно создавать объекты, классы придуманы не для этого.
- Методы классов, работающих с БД должны возвращать РЕСУРС и никак по-другому, лучше используйте while каждый раз когда получаете данные от класса.
- Обязательно делайте sql-запросы в циклах, это очень важно, иначе как вы получите все записи из таблицы?
- Храните дату и время в полях типа varchar, потому-что поле datetime имеет какой-то свой странный формат.
- Создайте себе поле в таблице, где для каждой записи будете дописывать через <br /> все изменения с записью, и обязательно именно так. Ни в коем случае не создавайте отдельную таблицу логов, зачем нам лишний файл на диске.
- Не создавайте много ячеек в таблицах БД, лучше используйте seialize и забудьте про кодировку при сохранении, если unserialize каждый раз выдает ошибку, просто игнорируйте её.
- Вообще игнорируйте ВСЕ ошибки в проекте, выключите error_reporting — он только мешает, не будьте задротами.
- Никогда, слышите, никогда не проверяйте переменную на существование, просто выводите её прямо в шаблон, после пункта 17, Notice для вас уже не проблема.
- Пишите только так
for($i=0; $i<count($arr); $i++), потому-что считать количество элементов в массиве при каждой итерации это хорошо, а постинкремент работает намного быстрее, а кто говорит наоборот просто не знает о чем говорит. И перебирать большой массив нужно именно сначала, потому-что так быстрее.
- Не используйте парсинг ни в каком виде, это очень плохо, лучше скачивайте страницу целиком вместе с версткой и сохраняйте её в БД прямо как получили, не тратьте время на парсинг, тем более использование DomDocument очень замедляет проект, и его же еще учить нужно, а вам некогда — надо проект писать.
- Храните всю информацию о пользователях в одной таблице — данные для авторизации, анкетные данные, домашние адреса и телефоны, места работы, да вообще любую информацию храните в одной таблице и не забывайте про serialize
- Не используйте индексы и ключи в БД, и тем более связи между таблицами, это очень плохо.
- Никогда не используйте таблицы-справочники, лучше дублируйте все в одной колонке, тем более если колонка содержит большие и часто повторяющиеся данные.
- Вы слышали про стандарт именования функций и методов? Забудьте! Кто вообще придумал что в именах функций должна быть какая-то логика, да и функции с именами a(), b(), aa() намного короче вызывать.
- Делайте функции как можно больше, если программисту лень читать что делает функция — он плохой программист.
- Никогда и нигде не пишите комментарии, потому-что тру-прогерам они не нужны, в худшем случае можно написать коммент типа /*это функция a(), она принимает две переменные $a и $b*/ для совсем тупых.
- Функции должны принимать как можно больше параметров, делать с ними кучу самых разных действий и возвращать всегда непредсказуемый результат, чтобы всё-таки заставить прогеров прочитать их исходники.
- Так как мы уже решили не использовать наследование, повторно писать функции с других классов, то надо дополнить это еще и тем, что класс должен быть не меньше 1000 строк, и чем он больше, тем лучше.
- Для того чтобы получить по-настоящему большой класс, нужно для каждой скобочки выделять целую строчку, нужно обязательно создать очень много свойств класса, на всякий случай, а еще мы помним что ни в коем случае нельзя использовать стандартные функции php — всегда пишем свои.
- И последнее, допустим что вам нужен скрипт, у которого действия меняются в зависимости от даты (а вдруг), обязательно пишите эту дату прямо в скрипт, чтобы каждый раз заходить и исправлять её руками, чтобы всегда держать скрипт под контролем.
Спасибо за внимание!
UPD
Публикация внезапно набрала отрицательный рейтинг, хотя всё что в ней изложено взято с реального кода.
Отвечаю на комментарии:
От lavkasnov и другие, кто затронул эту тему
Именно так советует PSR
Конечно, но не в случаях с циклами и условиями. см. PSR-2 5.1-5.6
От CentALT
Уважаемые профессионалы подскажите как правильно делать верстку чтобы не получилось как в 1 и 2?
Создавать отдельные файлы шаблонов, которые кстати можно подключать внезапно не используя echo
А вообще есть куча способов выводить информацию в шаблон без echo
Я например для таких целей использую DOM.
Т.е. у меня есть чистый html-шаблон, в котором расставлены псевдо-переменные, а шаблонизатор цепляя шаблон и зная сколько значений имеет переменная просто парсит нужный элемент верстки столько раз сколько нужно, а дальше через saveHTML выводит результат. В результате мы имеем чистые шаблоны, в которых только верстка, чистые скрипты в которых нет верстки и всего 1 echo на весь проект состоящий из нескольких сотен страниц и счастливых кодеров и верстальщиков так как ни те ни другие не боятся что кто-то может уронить проект или накрыть верстку. Для подробностей советую посмотреть старый добрый xTemplate (хотя сейчас есть более мощные аналоги вообще с полным разделением кода)
От G-M-A-X
На проде выключил E_NOTICE
display_errors само собой
Конечно, а потом благополучно можно засовывать несуществующие переменные прямо в шаблон и не морочить себе голову лишней информацией типа Notice, зачем вообще придумывали проверки на существование и проверки на пустоту, они же только усложняют код.
Комментарии (61)
SerafimArts
07.09.2016 19:55+8лучше используйте while каждый раз когда получаете данные от класса.
А чем это-то вредно? Можете рассказать чем плох такой код?
public function getResult() : \Generator { while ($result = $this->stmt->fetch(\PDO::FETCH_OBJ)) { yield $result; } }
McLotos
08.09.2016 08:59-1Тут всё просто. У вас есть 2 варианта действий:
1. Получить от модели готовый массив данных и сразу с ним работать
2. Каждый раз получать от модели ресурс и превращать его перебором в массив уже запределами модели.
Что предпочтительнее решать вам, но по-моему писать While в 1000 разных местах проекта намного лучше, чем всего 1 раз в самой модели, не правда ли? =)bat
08.09.2016 10:05+1не правда, вернее, не всегда
результаты больших выборок обрабатывать массивом неоптимально, а порой невозможно
smple
08.09.2016 10:41+1к сожалению не все так хорошо
если получили несколько записей, без разницы в массиве или в ресурсе то цикл все равно придется делать по записям (вы же не просто так список получили) и большой разницы по ресурсу или по массиву нет.
Плюсы ресурса
В некоторых базах ресурс это указатель на данные, которые на стороне БД это значит что в память application сервера они не загруженны.
В случае если цикл по ресурсу и вы точно знаете что данные потом не пригодятся вы можете после извлечения( fetch) эту переменную освободить и тем самым обрабатывать огромное количество данных, не грузя их единовременно в память application сервера.
Но да ситуации возникают крайне редко и в большинстве случаев удобней иметь именно массив.
G-M-A-X
07.09.2016 20:41-1Подключайте все файлы проекта в любом месте проекта даже если вам нужна всего одна функция.
Ну вряд ли кто-то вручную подключает все файлы.
А стоит ли использовать тяжеловесные фреймворки? :)
Используйте массив GLOBALS — без него вообще никак, разработчики языка придумали его для вашего удобства, а вот проблемы с закончившейся озушкой это проблемы сервера, а не языка.
Разве GLOBALS страшны закончившейся озушкой. Я такого не слышал :)
используйте циклы прямо в верстке
Хм, а как вывести список по другому? :)
Дублируйте один и тот же метод во всех классах каждый раз, когда он вам понадобится, забудьте про наследование это пережиток прошлого.
Лучше просто использовать метод/ф-ю без наследования.
Используйте только статические методы и свойства, не нужно создавать объекты, классы придуманы не для этого.
Когда существует только один инстанс/нету привязки у метода к инстансу, то часто так и делаю :)
выключите error_reporting — он только мешает
На проде выключил E_NOTICE
display_errors само собой
Храните всю информацию о пользователях в одной таблице — данные для авторизации, анкетные данные, домашние адреса и телефоны, места работы, да вообще любую информацию храните в одной таблице и не забывайте про serialize
Часто требования на старте одни, а потом другие, или вообще требования не формализированы. :)
В postgres можно нативно хранить массивы.
А иногда нужна денормализация. :)Akdmeh
07.09.2016 22:11+1В postgres можно нативно хранить массивы.
В MySQL тоже относительно недавно добавили тип JSON.G-M-A-X
08.09.2016 10:36-2Это чуть другое.
Ну и они не индексируются.
Но как вариант.
Хотя и раньше можно было сохранять JSON данные.Akdmeh
08.09.2016 12:04Конечно, я в первую очередь о том, что время идет, и функции добавляются (я был даже удивлен, что добавили JSON, так как наткнулся об этом чуть ли не случайно). Сначала, конечно, многого не хватает, но потом сделают определенные оптимизации и т.д., может еще со временем и добавят нужное.
Да и если подумать навскидку, мне кажется сомнительным индексировать по JSON, лучше уж тогда создать несколько дополнительных полей.
lavkasnov
07.09.2016 21:13+6> 29.Для того чтобы получить по-настоящему большой класс, нужно для каждой скобочки выделять целую строчку
Именно так советует PSR
Lure_of_Chaos
07.09.2016 23:54-329a. Но самое главное — разнообразие стилей. Будьте оригинальны!
class MyClass { public function f() { if (a == b) { .. } } }
OnYourLips
08.09.2016 00:37Нет, не для каждой, а только после классов и методов, причём только если список параметром умещается на одной строке.
Внимательнее читайте спецификацию ;)lavkasnov
08.09.2016 00:59А я где то писал, что после каждой? Внимательнее читайте комментарий
SerafimArts
08.09.2016 01:12+1Строго говоря вы опрвергали автора, используя его цитату, где он говорил именно про каждую скобочку.
Но в ваше оправдание отмечу, что мысль про PSR была ясна каждому (почти), учитывая простоту и очевидность рекомендации, а замечание от OnYourLips подозреваю, всего лишь придирки.
IvanCher
08.09.2016 09:02+131. Забудьте про PSR и Code-style. У каждого Senior PHP-программиста должен быть свой стиль. И вообщем у всех в команде должен быть свой стайл, не нужно быть подражалой.
IvanCher
08.09.2016 10:32+2блин, лучше не комментировать статьи про php и apple. Всегда крайне неожиданная реакция… то в плюс, то в минус :)
ErickSkrauch
08.09.2016 10:42PSR являются рекомендациями. Им можно следовать, а можно и не следовать.
IvanCher
08.09.2016 11:41-1К сожалению да, это лишь рекомендации, которым мало кто следует. В php-мире вообще мало кто чему-то следует, потому что нафиг надо учить еще какие-то рекомендации, шаблоны, бест практикс и прочее, ведь php нам позволяет всё фигачить, как угодно и не заморачиваться об этом. Да и поддержкой проектов не нужно заморачиваться — отстрочил сайтик за большие деньги, впарил его заказчику, а дальше пусть сам с ним парится.
Печальная правда жизни, только за что мне-то теперь минус лепить? Не я же таким php сделал :)SerafimArts
08.09.2016 11:48+1Мало кто? о_0 Я что-то не припомню популярного framework-agnostic (ну или зенд, симфони, лара...) кода пакета, который бы не следовал первым 4ём PSR.
IvanCher
08.09.2016 12:07+1Нормально Вы загнули :)
Я поэтому и пишу на симфони, потому что там хоть люди следуют этому и понимают важность этого.
Но в php это лишь мельчайшая часть от всего пирога.
Назовите лучше CMS, которая этому следует.
А тестами удобно покрывать приложения на yii? Вот честно, все кричат, что это легко делается, но постоянно вижу, что через пол года все на них забивают :) Да, конечно, заказчик против. Да просто там их писать намного сложнее, чем на том же симфони. И дело не в самих тестах, а в том, что просто ими покрывать код сложнее, ведь нафиг нам эти абстракции, мы от них отошли и налепили всё в кучу. DI в yii никакой, компоненты тестируются сложно, получение хоть чего из любой части кода тоже добавляет веселья к тестированию.
Ладно, простите, разошелся… Это же php, тут так принято и так все привыкли. Не стоит переусложнять.
Только не говорите — «Все? о_0 У нас все пишут слабосвязанный код, который легко поддается тестированию, локализации, валидации и прочему-прочему». Не верю!
На php это делать очень и очень сложно. Сам язык постоянно толкает на «схалтурить», и я не исключение. А те библиотеки, CMS, фреймворки и прочее является лишь логическим продолжением такого подхода.
Хотя Symfony 2+ реально задает тон для приложений, требующих серьезной долгосрочной поддержки, но его используют реально единицы даже серьезных проектов и компаний… ведь он таак слооожен, там же нужно столько шаблонов знать и думать, прежде чем код написать… не, нафиг, лучше возьмем yii, там можно халтурить, как и в остальном php :)
Хотя может, конечно, мир изменился, потому что я около 2х лет пытаюсь избегать в php CMS, самописных велосипедов, kohana, cake и т.п. Жаль, что редко это получается.
С ларавелем близко не сталкивался.lavkasnov
08.09.2016 12:44> Назовите лучше CMS, которая этому следует.
Можете посмотреть мою:
https://github.com/litepubl/cms
Не идеал, и если есть желание найти недостатки, то не сомневайтесь — они там есть. Штука в том, что нужно уметь выкрутиться не наплодив лишних сущностей. Впрочем это тема для отдельной большой статьи
ErickSkrauch
08.09.2016 12:49А тестами удобно покрывать приложения на yii?
^ Yii2, полгода проекту, функционал развивается, тесты пишутся, как unit, так и functional, всё очень даже удобно.IvanCher
08.09.2016 12:54Что Вы пишете? То про делфи, то про это.
Я говорю общую картину и объективные вещи, вы говорите какие-то узко-субъективные вещи.
Я тоже могу напрячься и написать тестируемый код на yii, но разговор про то, что это делать очень сложно, если работал с гораздо более удобными подходами.
Когда-то мне нравилось делать сайты на wordpress. Это реально мне казалось очень удобно и классно. Потом попробовал другое и стал постоянно плеваться от вордпресса. Сейчас просто попробовал еще что-то вкуснее, чем yii2, да и вкуснее, чем php :)ErickSkrauch
08.09.2016 13:01Про Delphi и про тестирование Yii2 я написал к тому, что не зная, не желая, не напрягаясь, делая на "отстань" можно действительно всегда делать откровенную хрень.
С другой стороны, если всё же напрячься (или вы считаете, что программист не должен напрягаться?), то можно из того и из другого извлечь множество профита. Ваше нежелание напрягаться и постоянный поиск новых инструментов, которые позволят меньше напрягаться («перешёл на Go, там же есть go fmt!!!!11») не означает, что те инструменты, в которых вы так и не разобрались, являются плохими.IvanCher
08.09.2016 13:50Я прекрасно знаю все кишки yii и первого, и второго. И написал на нем несколько крупных приложений. И работал в проектах, которые не я начинал писать. И также в проектах, где работает 2-4 программиста, а также где 20+ программистов. Это про «неразобравшись».
Про разные модные словечки, типа Go или Scala, это тема другого разговора.
Я считаю, что программист не должен напрягаться над написанием кода, он должен напрягаться над логикой приложения, его архитектурой(не в глобальном смысле) и над решением бизнес-задач.
Хочется много всего еще сказать, как в целом, так и про yii в частности, но пора бы и пойти поработать :)
Akdmeh
08.09.2016 12:12Думаю, есть разница между фреймворками и между продакшн кодом. Там все до сих пор бывает печально.
Хотя, о чем уже говорить, какой к черту PSR, мне если не нравится форматирование, есть автоформатировщики в IDE, которые приведут код к одному образцу. Меня больше волнует то, что я до сих пор часто прямое использование mysql_* функций…
Это хорошо, когда есть время отрефакторить, а иногда заказчику трудно объяснить, почему этот код плохой, если до сих пор рабочий…G-M-A-X
08.09.2016 12:57-3Меня больше волнует то, что я до сих пор часто прямое использование mysql_* функций…
Я и на php7 их использую, как абстракцию :)
Temirkhan
08.09.2016 11:33У «каждого» быть не должен. Оформление может варьироваться только в пределах проекта/команды. У программистов и так хватает своих особенностей в стиле написания кода. Если они еще и оформлять его будут каждый на свой лад, будет невозможно его читать.
IvanCher
08.09.2016 11:45Вы понимаете, что это пункт из вредных советов?
Если перевести его, то получится, что программисты уровня повыше должны знать общепринятые стандарты, знать их плюсы/минусы. А рядовые кодеры должны следовать код-стайлу, принятом в проекте/команде.
То есть, вы повторили то же, что я написал.
saksmt
07.09.2016 22:22-16Пожалуй это одна из лучших статей по PHP из песочницы за последнее время.
Добро пожаловать на хабр!
saksmt
08.09.2016 09:18Ого-го, целых 12 любителей тех замечательных статей из песочницы "как я делал свой велосипед на костылях и процедурном стиле в 2016 году". Это со мной что-то не так или же ...?
Temirkhan
08.09.2016 10:19+3Эта статья, в лучшем случае, «вредные советы для начинающих web-разработчиков»… А у начинающих разработчиков нет понимания «от обратного». Итого: развлекательный материал для joyreactor'а под специфичную аудиторию
saksmt
08.09.2016 21:57Я видел достаточно не «начинающих» разработчиков, которые на полном серьёзе считают, что хранить в базе сериализованые нативными средствами классы (да, именно классы, а не мапы) — хорошая идея, ещё и через `LIKE` умудряются по ним искать, да и в целом к БД почти у всех разработчиков достаточно наплевательское отношение. Есть ещё особая секта разработчиков — «мастера оптимизации», которые экономят на «скорости обработки типов строк» (т.е. давний холивар на тему `"` vs `'`) при этом используя тяжеловесные ORM, записывая в одну и ту же переменную разные типы, проходя один и тот же массив по 20 раз в разных местах ничего не меняя в промежутках и т.д.
Так что я действительно считаю, что это достойная статья (хоть может и публикация в пятничный вечер была бы более к месту). Особенно, как я уже подметил, на фоне остальных. И я правда искренне удивлён минусам как к своим комментариям, так и к статье.
P.S. Вот так вот неудачно оставишь благодарность и уже не сможешь использовать разметку в комментариях :( Так что уж извиняйте за голый markdown.Temirkhan
09.09.2016 17:46До тех пор, пока программист готов внимать и учиться, я смотрю сквозь пальцы на «такие» проблемы.
Да, было бы лучше писать в пятницу. У хабра немного не та душа, которой Вы ее для себя видите. Вы быстро привыкнете) И не сокрушайтесь по мелочамsaksmt
09.09.2016 21:58Так вот эта статья и есть для «учиться» :)
Да я-то как раз не удивлён (хоть и не приятно, что простая благодарность принимается настолько в штыки), как говорится «за страну обидно»
ellrion
08.09.2016 10:41+1Нет, просто статья так себе. Часть пунктов уровня «не суйте пальцы в розетку», по части есть желание услышать обоснования или поспорить.
McLotos
08.09.2016 10:41Да, они именно из серии «не суйте пальцы в розетку», но как я уже говорил примеры взяты с реальных проектов
saksmt
08.09.2016 22:13В дополнение к соседнему комментарию: есть очень много людей, которые очень любят пихать пальцы в розетку, среди обитателей хабра в том числе :)
Lure_of_Chaos
07.09.2016 23:59+431. Упаковывайте сложные выражения и проверки в одну строку, желательно вместе с объявлением переменной в условии:
if ($tru=($a==$b & $b==$c & $c+$d>$e?$f:$g)) { $this->do($tru); }
biggieman
08.09.2016 09:3216. Не создавайте много ячеек в таблицах БД, лучше используйте 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
iit
08.09.2016 09:41Серега, даже не знаю поздравить тебя или посочувствовать. Инвайт ты таки получил но карму тебе сразу слили.
Ну вряд ли кто-то вручную подключает все файлы.
А стоит ли использовать тяжеловесные фреймворки? :)
У него legacy проект где нет composer и из за кучей инклюдов в разных файлах он долго пытался понять где и что подключается.
Разве GLOBALS страшны закончившейся озушкой. Я такого не слышал :)
В том проекте храниться в них все, начиная от результатов выборки бд на более 1ккк строк, заканчивая данными из сессий пользователей.
Хм, а как вывести список по другому? :)
Тут мы постоянно спорим IRL — автор сразу создает DOM объект и рендерит уже чистый html добавляя в него данные списка. Я же юзаю laravel и использую конструкции for в blade
Когда существует только один инстанс/нету привязки у метода к инстансу, то часто так и делаю :)
В этом случае все ок, но когда все начиная от моделей и заканчивая шаблонами и бизнес-логикой сделано статикой, это превращается в ад.
Храните всю информацию о пользователях в одной таблице — данные для авторизации, анкетные данные, домашние адреса и телефоны, места работы, да вообще любую информацию храните в одной таблице и не забывайте про serialize
В проекте автора есть три таблицы на +100 полей причем в них есть 3-5 поля с php serialize на еще +50 полей. Причем некоторые serialize были поправлены без десериализации чьими-то кривыми ручками в базе и окончательно испорчены.McLotos
08.09.2016 09:42Ну вот зачем ты так спалил? Как бы у меня же не было задачи ругать чей-то код, я просто рассказал о том, что видел и что так я бы не делал. Да serialize в БД первое время реально бесил, сейчас его уже почти не осталось =)
stepmex
08.09.2016 10:39Интересно, когда уже программисты примут тот факт что count/sizeof не считает элементы массива, а на прямую обращается к данным о его размере.
Устал читать глупости про «не используйте count в циклах».SerafimArts
08.09.2016 11:51Это не отменяет лишний вызов функции внутри цикла. При избавлении от оного скорость возрастает (по прикидкам на php7.1 dev) примерно на 10-15%.
DevGood
08.09.2016 10:39+1Странные «вредные» советы. Похоже автору очень импонирует собственный, авторский, стиль написания кода. Любой другой стиль автоматически становится сборником неких вредных правил :) Добрее надо быть :)
P.S. Особенно порадовал пункт про скобочки.
G-M-A-X
09.09.2016 00:23-1UPD
Публикация внезапно набрала отрицательный рейтинг
От G-M-A-X
1. Если что, то я не могу минусовать… :)
2. Зачем мне сдалить E_NOTICE на проде? На деве — пожалуйста. :) А тем более с выводом на экран.
hamnsk
14.09.2016 12:01Ждем вторую часть с полезными советами и примерами, я вот не кодер но пишу что то для себя и было бы интересно перенять опыт хороший!
Onito
Совет 1. Быть пхп программистом(шутка)
qw1
Это номер 0.
barker
Какая уж тут шутка…