Notice: Undefined variable. Допустимо?

[Hint]

Постоянно спорим с коллегой по поводу isset и undefined variable. Он считает, что notice — ерунда, и не стоит тратить время на написание «дополнительных» проверок. Грубый пример:
Его вариант:
if ($_GET['query']) echo 'Передана строка запроса';
Мой вариант:
if (isset($_GET['query']) && strlen($_GET['query']) > 0) echo 'Передана строка запроса';

Более того, я частенько переписываю его код, добавляя дополнительные условия. Ну не нравится мне код, генерирующий notice, ничего не могу поделать.

Хотелось бы узнать ваше мнение.

[graber]

if (!empty($_GET['query'])) {
     // do something
}

а лучше:

if ($request->getParam('query')) {
     // TODO: решать проблему в корне
}

[Hint]

Empty вернет true в случае строки, содержащий '0'. Не всегда критично, но всё же.

Речь не о GET конкретно. Другой пример. Есть шаблон, в который может быть передано сообщение об ошибке для вывода (но ошибки может и не быть). В этом случае кто-то установит переменную в false, а кто-то вообще не будет ее создавать, а в шаблоне напишет:

<?php if ($error): ?>
<div class='error-msg'><?php echo $error ?></div>
<?php endif ?>

Опять же «безобидный» notice.

[homm]

Вот этот пример мне очень нравится. Сам постоянно с таким сталкиваюсь. Приходится всегда добавлять $error, даже со значением NULL.

[graber]

у меня так:

{if $error}
    <div class="error-msg">{$error}</div>
{/if}

[graber]

Никаких нотисов разумеется быть не должно. и на dev-сервере всегда стоит error_reporting(E_ALL);

Ну а реализация проверки всегда разная и зависит от обстоятельств
Иногда достаточно if (!empty($value)), а иногда нужно и что-то более сложное:

if (isset($_GET['query']) && trim($_GET['query']) !== '') {
    // ok
}

ну или в случае с использованием $request:

$query = $request->getParam('query');
if (trim($query) !== '') {
    // ok
}

[CharnaD]

Категорически «ЗА» isset.

[bogus92]

Когда нет notice то порой легче находить ошибки в коде. Бывает так, что случайно вместо REQUEST напишешь REQEUST — когда перечитываешь код и ищешь ошибку не всегда заметно, а notice с этой ошибкой вылезет все-равно и сразу видно будет.

[Umkus]

Первый вариант — скорей подход начинающего php-программиста. Причём свято верящего в то, что он абсолютно законен/целесообразен. ВСЁ что выводится на экран не спросясь — есть ошибка. А костыль, который прячет ошибку, вместо того чтоб исправить её, есть говнокод. Опытного программиста такие вещи должны раздражать по определению.

[kirsan_vlz]

Я вообще взял за правило в рабочей версии (не продакшн) error_reporting в E_ALL|E_STRICT и чтобы ни единого сообщения от интерпретатора.
В принципе, если не быдлокодить, то не нужно прилагать особые усилия чтобы получить strict код.
Кстати вроде бы в 6-й версии интерпретатора E_STRICT в E_ALL будет входить.

[AterCattus]

php.net...errorfunc.constants.php
Тут написано, что E_STRICT не входит в E_ALL только в PHP < 6. Так что ваше предположение верно.

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

[kvf77]

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

[symbix]

Дело не в том, что «медленнее работает»-«быстрее писать».

Дело в том, что notice — это куча полезной информации, хотя бы — как минимум — об опечатках в именах переменных и ключах массовов. И отключая notice-ы, разработчик лишает себя полезного инcтрумента отладки.