Comments 28
Тем, что если в вашем классе есть метод __get(), но нет метода __isset(), ваш код «сломается»
если у вас такой код, то он уже сломан
спасибо за 3 вещи:
1. за то, что напомнили про то, что вышла 7.0.6
2. за то, что вкратце описали ключевую вещь, а то сначала бы поставил(пусть и в dev), а потом прочел, как обычно.
3. за то, что косвенно помогли оптимизировать мой говнокод — залез на свежую голову, сделал человеческую проверку.
1. за то, что напомнили про то, что вышла 7.0.6
2. за то, что вкратце описали ключевую вещь, а то сначала бы поставил(пусть и в dev), а потом прочел, как обычно.
3. за то, что косвенно помогли оптимизировать мой говнокод — залез на свежую голову, сделал человеческую проверку.
От empty() пора избавляться, ИМХО.
альтернативу не подскажите?
Я соглашусь с товарищем выше, пусть и не в такой категоричной форме.
Всегда приятнее видеть в коде что-то вроде null === $value или 0 == $value вместо empty($value)
Явное лучше неявного в любом языке. К PHP это относится особенно.
Всегда приятнее видеть в коде что-то вроде null === $value или 0 == $value вместо empty($value)
Явное лучше неявного в любом языке. К PHP это относится особенно.
по-моему, дело вкуса…
Пока вы волк-одиночка — да, для вас это будет дело вкуса.
Однако в любой более-менее крупной команде есть стиль кода. И несоблюдение этого стиля чревато выпиливанием из команды.
Однако в любой более-менее крупной команде есть стиль кода. И несоблюдение этого стиля чревато выпиливанием из команды.
Если вы — в команде, и в этой команде есть «стиль кода», то о чём тогда тут вообще говорить? :)
По-моему, либо ты в команде и, соответственно, подчиняешься правилам — и тогда нет никаких проблем и поводов для дискуссии о том, от чего надо избавляться, либо ты не в команде — и в этом случае тоже нет причин для споров. :)
P.S. На мой взгляд — да, «явное лучше неявного». Даже когда я не в команде… :)
По-моему, либо ты в команде и, соответственно, подчиняешься правилам — и тогда нет никаких проблем и поводов для дискуссии о том, от чего надо избавляться, либо ты не в команде — и в этом случае тоже нет причин для споров. :)
P.S. На мой взгляд — да, «явное лучше неявного». Даже когда я не в команде… :)
Однако в любой более-менее крупной команде есть стиль кода.
писать всегда только явные проверки или только empty это плохой "стиль кода" команды. Это даже не стиль кода, это способ оформления логики и выражения мысли, а в этом плане важна гибкость.
Я поступаю проще. За "стиль кода" у меня отвечают статические анализаторы и фиксеры кодинг стайлов, и мне в принципе плевать что использует разработчик в своем проекте (в рамках моей команды) пока он покрывает это тестами и знаете что делает.
Хм. Наоборот недавно переучился писать empty() и is_null(), вместо === null или == 0, или еще хуже !$value
Думаю, однозначного ответа как лучше нет
Думаю, однозначного ответа как лучше нет
empty() это удобный синтаксический сахарок прежде всего:
empty($array[$key]) ~ !isset($array[$key]) || $array[$key] == false
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($array)) при работе с массивами, нежели получать количество его элементов, для сравнения, вроде (count($array) == 0).
empty — это возможность понять, есть ли в переменной, что-то важное и если нет — не обращать на нее внимания. Тогда, как прямое сравнение — это возможность убедится что переменная не является null (хотя по прежнему может быть «ненужной», например содержать пустую строку или 0 (если это целое число)).
Я хочу сказать что нужно действовать по ситуации, если переменная может быть равна пустой строке (если это допускается приложением), но не может быть равна null — Вам необходима прямое сравнение, если необходимо проверить наличие в переменной данных, для дальнейшего использования — я не вижу смысла писать условие, в котором перечислены все возможные исключающие ситуации, а проще воспользоватся функцией которая именно для этого предназначена.
Лаконичнее же, данное решение, мне кажется из-за естественности написания. Вы ведь согласитесь, что «если массив не пустой то...» выглядит куда более естественно, нежели «если количество элементов в массиве равно нулю» уже как-то не очень.
Использовать можно и тот и другой вариант, по поводу же стайл-гайдов, то я не думаю, что есть хоть одна группа разработчиков, запрещающая использовать функцию empty (как нативный инструмент языка), своим программистам — это (использования тех или иных функций), собственно, на мой взгляд вообще не должно входить в стайл-гайды.
Так empty — это не только проверка на 0 и null…
Variables by reference with goto
Oh, really?
Да, разумеется, это баг. Я не спорю. Но степень его экзотичности на два порядка больше, чем у того, что описано в статье. По крайней мере я не видел ни одного production-ready фреймворка, использующего goto.
меня зацепило вот этим https://github.com/zendframework/zend-code/issues/49
да и на самом деле, там сломали вот это Bug #71914 Reference is lost in case, а «Variables by reference with 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
Опять же проблемы будут только у тех кто по каким-то причинам очень любит ссылки.
Полезная статья. Спасибо автору. Сделал английский перевод статьи.
Sign up to leave a comment.
Обновление PHP до 7.0.6 может «сломать» ваш код