Почему я должен исправлять ошибки E_NOTICE?

РЕЗЮМЕ

PHP Runtime Configuration Docs дает вам представление о том, почему:

Включение E_NOTICE во время разработки имеет определенные преимущества.

Для целей отладки: сообщения 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 предупреждения 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 , PHP напечатал сообщение об ошибке:

 Notice: Use of undefined constant username - assumed 'username' in /home/user/example2.php on line 8 fred 

3. ЛУЧШАЯ ПРИЧИНА

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

Поскольку E_NOTICE указывает на ошибку .
PHP просто слишком прощает, чтобы назвать это.

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

Это может вызвать уведомление, но будет работать по назначению, поэтому вы игнорируете уведомление:

 if ($_GET['foo']) ... 

Это, с другой стороны, будет тратить половину вашего дня, пока вы игнорируете уведомление и пытаетесь выяснить, почему ваша функция « bar() не работает»:

 $foo = bar(); if ($too) ... 

Если вы не «исправите» прежний случай, где переменная может законно не существовать, вы не сможете осмысленно использовать уведомления, чтобы поймать опечатку во втором случае.

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

Такие ошибки являются хорошей практикой для исправления, так как они называются «запах кода», они намекают на другую проблему (например, неправильные имена переменных или использование неопределенных переменных / неправильное использование методов), или они, вероятно, вызовут ошибки когда вы отражаете / расширяете систему.
Конечно, то, что я сказал здесь, не соответствует 100% случаев.

Бен, я думаю, это отличный вопрос. Правда, это хорошая практика для того, чтобы попытаться исправить любые ошибки, даже не смертельные, если только это не будет препятствовать проектируемой (и, следовательно, желаемой) функциональности системы. Более того, любой уровень ошибки указывает на то, что:

a) Что-то не так с вашим кодом, или b) вы написали код, который устарел, или написали код, который в противном случае нестабилен и, следовательно, подвержен побочным эффектам.

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

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

На самом деле это оправдание (или против) исправления ошибки сегодня, независимо от уровня ошибки.

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

Я также видел аргументы, что более эффективно избегать ошибок