Как разработчик, я работаю с включенным E_NOTICE. Недавно, однако, меня спросили, почему ошибки E_NOTICE должны быть исправлены. Единственная причина, по которой я мог придумать, это то, что лучше всего исправить эти проблемы.
Есть ли у кого-нибудь еще какие-либо причины, чтобы оправдать дополнительное время/затраты, потраченные на устранение этих проблем?
В частности, почему менеджер должен тратить деньги на исправление, если код уже работает?
СУЩНОСТЬ
PHP Runtime Configuration Docs дает вам некоторое представление о том, почему:
Включение E_NOTICE во время разработки имеет некоторые преимущества.
В целях отладки: сообщения NOTICE будут предупреждать вас о возможных ошибках в вашем коде. Например, предупреждается использование неназначенных значений. Крайне полезно находить опечатки и экономить время для отладки.
Уведомления будут предупреждать вас о плохом стиле. Например, $arr [item] лучше записывать как $arr ['item'], поскольку PHP пытается обрабатывать "item" как константу. Если он не является константой, PHP предполагает, что это строковый индекс для массива.
Здесь более подробное объяснение каждого...
1. ДЛЯ ОПРЕДЕЛЕНИЯ ТИПОВ
Основной причиной ошибок E_NOTICE является опечатка.
Пример - notice.php
<?php
$username = 'joe'; // in real life this would be from $_SESSION
// and then much further down in the code...
if ($usernmae) { // typo, $usernmae expands to null
echo "Logged in";
}
else {
echo "Please log in...";
}
?>
Выход без E_NOTICE
Please log in...
Неправильно! Вы не это имели в виду!
Вывод с E_NOTICE
Notice: Undefined variable: usernmae in /home/user/notice.php on line 3
Please log in...
В PHP переменная, которая не существует, возвращает null, а не вызывает ошибку, и это может привести к тому, что код будет вести себя иначе, чем ожидалось, поэтому лучше всего прислушаться к предупреждениям E_NOTICE.
2. ДЛЯ ОБНАРУЖЕНИЯ ПОКАЗАТЕЛЕЙ МАССИВНОГО МАССА
Он также предупреждает вас о индексах массивов, которые могут измениться на вас, например.
Пример - код выглядит сегодня следующим образом
<?php
$arr = array();
$arr['username'] = 'fred';
// then further down
echo $arr[username];
?>
Выход без E_NOTICE
fred
Пример - завтра вы включите библиотеку
<?php
// tomorrow someone adds this
include_once('somelib.php');
$arr = array();
$arr['username'] = 'fred';
// then further down
echo $arr[username];
?>
, и библиотека делает что-то вроде этого:
<?php
define("username", "Mary");
?>
Новый выход
Пусто, так как теперь он расширяется до:
echo $arr["Mary"];
и нет клавиши Mary в $arr.
Вывод с E_NOTICE
Если только программист имел E_NOTICE on, PHP напечатал бы сообщение об ошибке:
Notice: Use of undefined constant username - assumed 'username' in /home/user/example2.php on line 8
fred
3. ЛУЧШАЯ ПРИЧИНА
Если вы не исправите все ошибки E_NOTICE, которые, по вашему мнению, не являются ошибками, вы, вероятно, будете довольны и начнете игнорировать сообщения, а затем в один прекрасный день, когда произойдет реальная ошибка, вы не заметите он.
Потому что E_NOTICE указывает на ошибку.
PHP просто слишком прощает, чтобы называть это.
Например, при доступе к переменной undefined создается E_NOTICE.
Если это происходит часто, например, потому что вы не правильно инициализируете свои переменные, а ваше приложение бросает уведомления по всему месту, , как вы собираетесь рассказать разницу между "переменной, которая работает просто отлично, неинициализирована" и раз, когда у вас действительно толстое имя переменной?
Это может вызвать уведомление, но будет работать так, как предполагалось, поэтому вы игнорируете уведомление:
if ($_GET['foo']) ...
Это, с другой стороны, будет тратить половину вашего дня, пока вы игнорируете уведомление, и пытаетесь выяснить, почему ваша функция "bar() не работает":
$foo = bar();
if ($too) ...
Если вы не "исправите" прежний случай, где переменная может быть законно не существовать, вы не сможете использовать заметки, чтобы уловить опечатку во втором случае.
Уведомления помогут вам отладить ваше приложение. Если вы проигнорируете их, вы только усложняете свою жизнь.
Такие ошибки являются хорошей практикой для исправления, поскольку они называются "запахом кода", они намекают на другую проблему (например, неправильные имена переменных или использование переменных undefined/неправильное использование методов), или они будут вероятно, вызывают ошибки в дороге, когда вы отражаете/расширяете систему.
Конечно, то, что я сказал здесь, не соответствует 100% случаев.
Бен. Думаю, это отличный вопрос. Правда, это хорошая практика для того, чтобы попытаться исправить любые ошибки, даже не смертельные, если только это не будет препятствовать проектируемой (и, следовательно, желаемой) функциональности системы. Кроме того, любой уровень ошибки указывает, что либо:
a) Что-то не так с вашим кодом, или, b) Вы написали код, который устарел, или написали код, который в противном случае нестабилен и, следовательно, подвержен побочным эффектам.
Поэтому я считаю, что если временная шкала и бюджет проекта позволяют это сделать, вы всегда должны стремиться исправлять как можно больше ошибок, даже если они незначительны с точки зрения их влияния на конечный продукт.
Конечно, в анализе затрат и выгод есть определенный уровень принятия риска, поэтому вполне может быть, что менеджеры, контролирующие исход проекта, готовы хеджировать потенциальные будущие затраты на фиксацию известного проблема с нынешним временем и сбережение затрат ассоциируется с не исправлением ошибки. Математика в основном работает так, как вы думаете: если PV стоимости исправления ошибки в будущем меньше, чем деньги, спасенные сегодня, не исправляя ошибку, тогда вы не должны ее исправлять. С другой стороны, если PV стоимости исправления ошибки в будущем больше, чем деньги, спасенные сегодня, не исправляя ее, тогда вы должны ее исправить сегодня.
На самом деле это оправдание (или против) исправления ошибки сегодня, независимо от уровня ошибки.
Часто они указывают на логические ошибки или опечатки. Они помогут вам выявить ситуации, когда вы ошибочно указали имя переменной или пытаетесь использовать переменную до ее установки.
Я также видел аргументы, что он эффективнее избегать ошибок