Pull to refresh

Comments 28

Тем, что если в вашем классе есть метод __get(), но нет метода __isset(), ваш код «сломается»

если у вас такой код, то он уже сломан
Поискал по vendor и увидел, что много где такие проблемы. Печально.
спасибо за 3 вещи:
1. за то, что напомнили про то, что вышла 7.0.6
2. за то, что вкратце описали ключевую вещь, а то сначала бы поставил(пусть и в dev), а потом прочел, как обычно.
3. за то, что косвенно помогли оптимизировать мой говнокод — залез на свежую голову, сделал человеческую проверку.

альтернативу не подскажите?
Я соглашусь с товарищем выше, пусть и не в такой категоричной форме.

Всегда приятнее видеть в коде что-то вроде null === $value или 0 == $value вместо empty($value)

Явное лучше неявного в любом языке. К PHP это относится особенно.
по-моему, дело вкуса…
Пока вы волк-одиночка — да, для вас это будет дело вкуса.
Однако в любой более-менее крупной команде есть стиль кода. И несоблюдение этого стиля чревато выпиливанием из команды.
Если вы — в команде, и в этой команде есть «стиль кода», то о чём тогда тут вообще говорить? :)

По-моему, либо ты в команде и, соответственно, подчиняешься правилам — и тогда нет никаких проблем и поводов для дискуссии о том, от чего надо избавляться, либо ты не в команде — и в этом случае тоже нет причин для споров. :)

P.S. На мой взгляд — да, «явное лучше неявного». Даже когда я не в команде… :)
Однако в любой более-менее крупной команде есть стиль кода.

писать всегда только явные проверки или только empty это плохой "стиль кода" команды. Это даже не стиль кода, это способ оформления логики и выражения мысли, а в этом плане важна гибкость.


Я поступаю проще. За "стиль кода" у меня отвечают статические анализаторы и фиксеры кодинг стайлов, и мне в принципе плевать что использует разработчик в своем проекте (в рамках моей команды) пока он покрывает это тестами и знаете что делает.

Хм. Наоборот недавно переучился писать empty() и is_null(), вместо === null или == 0, или еще хуже !$value
Думаю, однозначного ответа как лучше нет
empty() это удобный синтаксический сахарок прежде всего:

empty($array[$key]) ~ !isset($array[$key]) || $array[$key] == false
Мне кажется, что empty гораздо удобнее и логичнее использовать в различных ситуациях. Да и просто приятнее написать (!empty($foo)), нежели ($foo !== null || $foo != ""), хотя делают оба варианта одно и тоже.

Так же само мне приятнее использовать (!empty($array)) при работе с массивами, нежели получать количество его элементов, для сравнения, вроде (count($array) == 0).

empty — это возможность понять, есть ли в переменной, что-то важное и если нет — не обращать на нее внимания. Тогда, как прямое сравнение — это возможность убедится что переменная не является null (хотя по прежнему может быть «ненужной», например содержать пустую строку или 0 (если это целое число)).
Я хочу сказать что нужно действовать по ситуации, если переменная может быть равна пустой строке (если это допускается приложением), но не может быть равна null — Вам необходима прямое сравнение, если необходимо проверить наличие в переменной данных, для дальнейшего использования — я не вижу смысла писать условие, в котором перечислены все возможные исключающие ситуации, а проще воспользоватся функцией которая именно для этого предназначена.

Лаконичнее же, данное решение, мне кажется из-за естественности написания. Вы ведь согласитесь, что «если массив не пустой то...» выглядит куда более естественно, нежели «если количество элементов в массиве равно нулю» уже как-то не очень.

Использовать можно и тот и другой вариант, по поводу же стайл-гайдов, то я не думаю, что есть хоть одна группа разработчиков, запрещающая использовать функцию empty (как нативный инструмент языка), своим программистам — это (использования тех или иных функций), собственно, на мой взгляд вообще не должно входить в стайл-гайды.
Мне кажется, что ваш длинный и, безусловно, ценный комментарий немного не по теме статьи.

Зато по теме ветки комментариев.

Так empty — это не только проверка на 0 и null…
Variables by reference with goto


Oh, really?

Да, разумеется, это баг. Я не спорю. Но степень его экзотичности на два порядка больше, чем у того, что описано в статье. По крайней мере я не видел ни одного production-ready фреймворка, использующего goto.
symfony2 https://github.com/symfony/symfony/blob/f29d46f29b91ea5c30699cf6bdb8e65545d1dd26/src/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php#L271
ни одного production-ready фреймворка, использующего goto

в любой реализации конечного автомата (парсеры например) можно наткнуться на goto. Другой вопрос что бага никак не связана с goto, а скорее сломали свитч: https://bugs.php.net/bug.php?id=71914


Опять же проблемы будут только у тех кто по каким-то причинам очень любит ссылки.

Какой смысл было публиковать ссылку на хабре а не на рэддите том же? Там выхлоп был бы посущественнее, там же обитают core-разработчики пыха.

Ссылку привел не ради пиара (кому интересно читать тот же материал на другом языке?), а с целью ознакомления: возможно кто-то захочет поделиться данной информацией с зарубежными коллегами.

И потому я и говорю — поделитесь ссылкой на реддите от своего имени.

Благодарю Вас за совет. Уже сделал.
Sign up to leave a comment.

Articles