Удляете ли вы в PHP внимание warning'ам?

Question

[HeBonpoc]

Простейший пример:
if($_GET['ajax'] == '1')
Warning
if(isset($_GET['ajax']) && $_GET['ajax'] == '1')
Лишний код не несущий смысловой нагрузки.

Так ли страшны warning'и? Стоит ли разрабатывать с error_reporting(E_ALL) и стремиться к полному отсутствию системных сообщений? Или забить и использовать простоту синтаксиса PHP?

Comments

[lightalex]

Насколько я понимаю, сейчас можно делать вот так: if (($_GET['ajax'] ?? false) == '1')
Это я так, вдруг кто сюда зайдет с поисковика, как я :)

Answer 1

[Roquie]

> Стоит ли разрабатывать с error_reporting(E_ALL) и стремиться к полному отсутствию системных сообщений?
стремись, и да, еще как стоит.

Разрабатывать надо так, чтобы даже ошибок уровня E_NOTICE небыло.

Советую к прочтению getjump.github.io/ru-php-the-right-way

Comments

[HeBonpoc]

Спасибо за статью! Обязательно прочитаю.

[Володимир Годяк]

error_reporting(E_ALL) всегда использую)

[HeBonpoc]

Статьи безусловно полезная, но тема моего вопроса не раскрыта.

[Roquie]

@HeBonpoc, по теме, я написал выше ссылки. А руководство необходимо для общего развития и понимания, куда стоит двигаться в мире PHP.
Кстати, собачки (@) которые блокируют ошибки использовать как постоянное решение категорически нельзя.

Answer 2

[Сергей Протько]

А вы как думаете? Варнинги допустимы, но крайне не желательны. На то они и варнинги, иначе бы просто смысла в них небыло. Есть варнинги показывающие, что были использованы устаревшие средства языка, которых в новой версии уже может и не быть. Или какой-то метод устаревший, и при обновлении библиотек/php ваш код просто сломается.

Проблемы же "лишнего кода" решаются обертками и слоями абстракций:

// метод класса Request
function get($name, $defaultValue = null) {
    if (!isset($_GET[$name])) return $defaultValue;
    return $_GET[$name];
}

$isAjax = 1 == $request->get('ajax', 0);

Попробуйте symfony/httpkernel в качестве обертки и уровня обстракции для обработки запросов.

Answer 3

[Сергей]

Суть ворнинга в примере Вашем в том, что возможно Вы ожидаете, что в get будут данные, но их может и не быть, или они будут переданы неправильные, тогда вся логика программы пойдет не туда, могут быть ошибки и серьезные последствия, именно поэтому php как бы намекает нам на это. А еще господин @fesor всё правильно сказал.

Comments

[HeBonpoc]

В моём примере ворнинг как раз бесполезен. Если переменная не установлена, то и равна нужному значению она не может быть, так что моя программа пойдёт куда надо. А как вам такой пример:
$response = someSuperGetJson($url);
$response = json_decode($response, true);
if($response['result']['success']['code'] == 41)
{
// код
}

If при всех проверках превратится в
if(isset($response['result']) && and is_array($response['result']))
if(isset($response['result']['success']) && and is_array($response['result']['success']))
if(isset($response['result']['success']['code']) && and is_numeric($response['result']['success']['code']) && $response['result']['success']['code'] == 41)
{
// код
}

[HeBonpoc]

Можно конечно сократить код, но всё-равно он будет лишним. Или суть в том, что при правильно построенной логике такого кода просто нигде не будет?

[Сергей]

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

[Roquie]

> If при всех проверках превратится в
ох, рассмешили :)

хватит

if(isset($response['result']['success']['code']) && $response['result']['success']['code'] == 41 ) 
{
 // do something...
}

Поясняю:
1. json_decode со вторым аргументом всегда вернет массив (при отсутствии ошибок во входных данных первого аргумента). Поэтому проверка на is_array излишна;
2. Проверять каждый вложенный элемент массива нет смысла, если мы используем только code; (для разных кодов можно switch сделать)
2. Проверка на is_numeric тоже не нужна. PHP при сравнении двойным равно (==) будет использовать нестрогое сравнение. Будь 41 строка или число, результат будет истиной. Для строгого сравнения используется оператор ===;

[HeBonpoc]

@Roquie спасибо за ваш комментарий — хорошо всё объяснили

Answer 4

[Cyapa]

Вот решат ребята в какой-нибудь 6й версии PHP выбывать ошибку при обращении к несуществующему элементу массива и накроются все ваши проекты при первом же обновлении.

Утрирую, конечно, но стремиться к тому, что бы не было ошибок (любых уровней) безусловно стоит.

Comments

[HeBonpoc]

Прочитайте, пожалуйста, мой коммент к ответу @butteff. Что вы об этом думаете?

[Cyapa]

Да, в вашем примере пока нет никаких шансов на неправильное исполнение. Но это пока. Мало ли, что будет дальше.

Лучше всего воспользоваться кодом на подобии того, что написал @Fesor. Тогда проверка не будет выглядеть столь огромной.