PHP @ вместо isset для проверки значения $_GET

Дайте мне одну вескую причину сделать это

if( isset($_GET['key']) && ($_GET['key'] === '123') )
{...

вместо этого

if( @$_GET['key'] === '123' )
{...

Я прошу именно этот вариант кода, а не вообще!

Не приветствуются следующие причины:

  • «использование @ замедлит работу приложения на несколько наносекунд, потому что ошибка все равно создается (даже если она подавлена).» Ну, я предпочитаю более медленный код, но более читаемый.
  • «использование @ — плохая привычка.» В целом это может быть правдой, но я не верю в этот случай (более того, вредные привычки могут зависеть от контекста, в руководстве по PHP в функции типа fopen они предлагают чтобы использовать @ в определенных обстоятельствах, см. Ошибки/Исключения на http://www.php.net/manual/en/function.fopen.php)

person Marco Demaio    schedule 22.02.2013    source источник
comment
Итак, вы считаете, что подавление ошибок делает ваш код более читабельным?!? втф!   -  person Mark Baker    schedule 22.02.2013
comment
Хотя вы могли бы сделать это, почему бы просто не определить глобальную функцию GET или что-то в этом роде?   -  person Waleed Khan    schedule 22.02.2013
comment
Восстанавливаемость. Обычная сортировка isset сделает невозможным определение того, была ли переменная не установлена, всегда молча заменяйте ее замещающим значением. Подавление @ обратимо. Если вы абсолютно уверены, что вам не нужно что-то отлаживать позже, используйте isset. Используйте @, если входной параметр может иметь решающее значение или иметь отношение к безопасности (а затем используйте обработчик ошибок ведения журнала).   -  person mario    schedule 22.02.2013
comment
@MarkBaker: нет, но в данном случае да. Я ясно сказал не вообще. Давайте не будем начинать войну из-за этого. Я жажду хорошей простой причины/ответа.   -  person Marco Demaio    schedule 22.02.2013
comment
Парафаза: Вот две отличные причины не делать то, что мне нравится, но дайте мне третью.   -  person Ray    schedule 22.02.2013
comment
Вы имеете в виду !== или === ? Большая разница. Если вы используете ===, я считаю, что нет причин не использовать @GET[], хотя я бы не стал этого делать, а вместо этого создал бы оболочку. (по строкам get_getpost($name, $type) )   -  person Bart Friederichs    schedule 22.02.2013
comment
Почему вы хотите подавить свои ошибки?! вы также можете использовать код без ссылки, включить error_reporting(0);, а затем опубликовать. Вы не знаете, какие проблемы скрывались за подавлением. Глупая идея/вопрос.   -  person Daryl Gill    schedule 22.02.2013
comment
@BartFriederichs: я исправил ошибку, которую имел в виду === для обоих.   -  person Marco Demaio    schedule 22.02.2013
comment
В качестве альтернативы и особенно для входных параметров есть альтернатива, позволяющая избежать синтаксической соли: sourceforge.net/ p/php7framework/wiki/input -- Он выполняет isset/@ за кулисами и позволяет повторно включать уведомления, если это необходимо, дополнительно выполняет некоторую фильтрацию. Так что вы можете просто использовать if ($_GET["key"]==="123") или даже if ($_GET->int["key"]===123), не беспокоясь.   -  person mario    schedule 22.02.2013


Ответы (3)


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

Основная проблема, связанная с использованием оператора @, заключается в том, что он, вероятно, станет соглашением в вашем коде, поэтому, хотя ваш пример может показаться безобидным, позже вы или ваша команда можете обнаружить, что вы или ваша команда используете:

if( @IsAvailable() ) {

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

person Fenton    schedule 22.02.2013
comment
Да, я считаю, что это самая важная причина, по которой я этого не делаю. Сокрытие ошибок позже в вашем коде, о которых вы, возможно, захотите узнать. +1 - person EM-Creations; 22.02.2013

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

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

person mcryan    schedule 22.02.2013
comment
использование @ замедлит работу приложения на несколько наносекунд, потому что ошибка все равно создается (даже если она подавлена). Ну, я предпочитаю более медленный код, но более читаемый. - person Nick; 22.02.2013
comment
Вы когда-нибудь профилировали какой-либо код? Возможно, вы также используете только одинарные кавычки? - person mario; 22.02.2013
comment
Ну, я предпочитаю более медленный код, но более читаемый. Хм... не обязательно слова мудрости. - person Ray; 22.02.2013
comment
@mario У меня есть профилированный код, но не для того, чтобы специально проверять разницу оператора @. Какая разница в использовании одинарных/двойных кавычек? - person mcryan; 22.02.2013
comment
@mario: что не так с одинарными кавычками, разве они не лучший выбор, чем двойные кавычки, когда мне не нужна строка синтаксического анализа для $ varibales? Вы предлагаете мне использовать двойные кавычки для `=== 123`? - person Marco Demaio; 22.02.2013
comment
stackoverflow.com/questions/482202/ - person mcryan; 22.02.2013
comment
@MarcoDemaio Конечно, зависит. Тогда с точки зрения удобства они предпочтительнее. Лично я больше ценю визуализацию и предпочитаю двойные кавычки для подсветки синтаксиса или использую их для различения текстовых и константных строковых литералов. Разница в производительности tokenizer посредственная. -- И если бы приложение состояло только из пяти миллиардов строк, это, возможно, имело бы незначительное значение. Так же, как с использованием @ (это, кстати, генерация уведомлений, а не подавление). - person mario; 22.02.2013

Если вы не принимаете проблему производительности в качестве аргумента, то это действительно нормально. Но это не обязательно должно быть во всех случаях, потому что @ подавит все возможные ошибки, даже те, о которых вы не подумали. Но в этом случае кажется, что другие ошибки, кроме той, которую вы хотите подавить, невозможны.

Я согласен с вами, что использовать isset() перед чтением значения очень некрасиво, и я тоже не люблю его писать. Но вставка @ перед оператором кажется мне уродливой. Это может снизить читаемость более длинного кода.

Хорошая новость заключается в том, что, начиная с PHP 7, мы можем использовать гораздо более приятный способ, оператор нулевого объединения ??, который работает следующим образом:

if($_GET['key'] ?? '' === '123' ) {}

Это в основном замена для этого:

$result = isset($value) ? $value : $anotherValue;

теперь вы можете использовать

$result = $value ?? $anotherValue;
person micropro.cz    schedule 23.02.2016