Стоит ли исправлять предупреждения интерпретатора PHP?

Question

[Finesse]

У меня с коллегой возник спор. В своих проектах он включает вывод предупреждений (E_NOTICE) PHP и всех их исправляет. Я же предпочитаю более локаничный и чистый код, поэтому вывод предупреждений отключаю и их исправлениями не занимаюсь. Напомню, что при включении предупреждений выводятся сообщения о необъявленных переменных и индексах массивов.

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

Я вижу следующие достоинства вывода предупреждений:

• Сразу узнаёшь об опечатке в названии переменной или индекса массива.
  

Недостатки:

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

Доводы "потому что так делают в Google" или подобные просьба не писать. Пожалуйста, пишите конкретные случаи, подтверждающие вашу точку зрения.

Answer 1

[Дмитрий Энтелис]

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

Напомню, что при включении предупреждений выводятся сообщения о необъявленных переменных и индексах массивов.

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

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

PS

Больше приходится писать код, меньше сил остаётся на разработку.

Разработка это и есть написание кода который максимально правильно работает при любых внешних условиях.

Comments

[Finesse]

"Если у Вас отключены нотисы - возникает огромный ворох плавающих ошибок с целостностью данных которые вы никогда не поймаете. Условно в каких то случаях модель вернула объект в котором какого то поля не хватает. Если ошибки включены - вы это увидите и исправите. Если выключены - php молча подставит дефолтное значение." — спасибо.

[Finesse]

P.S. "Я в шоке от того что люди на полном серьезе задают такие вопросы." — уверен, Вы когда-то тоже учились и задавали "глупые" вопросы.

Answer 2

[neol]

Конкретный случай из недавней практики: страница периодически генерировалась на 4 секунды дольше, чем могла бы, потому что кто-то когда-то забил на предупреждение. Естественно за этим предупреждением стояла ошибка в логике. ИЧСХ, за предупреждением почти всегда стоит ошибка в логике или кучка неиспользуемого кода.

Большая вероятность неожиданно получить сообщение о предупреждении, что в некоторых случаях нарушает работоспособность сайта.

На продакшене никакие ошибки в вывод попадать не должны никогда. Кстати говоря, разгребать логи php за разработчиками, которые забивают на предупреждение - весьма сомнительное удовольствие.

Больше приходится писать код, меньше сил остаётся на разработку.

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

Comments

[Finesse]

Спасибо. Просто часто бывают ситуации ситуации, в которых предупреждения возникают не из-за ошибки в логике, а, например, при проверке, установлен ли checkbox: if($_GET['check']) { ... }. В этом случае я подразумеваю одновременно проверку на наличие индекса и является ли значение истинным, но использую при этом более компактный код.

[Дмитрий Энтелис]

Finesse: в данном случае сам бог велел написать 1 раз в жизни несложную обертку

class input {

	/**
	 * Возращает значение либо пустую строку
	 * @param string $key
	 * @param string $def
	 * @return string
	 */
	static function post($key, $def = null) {
		return isset($_POST[$key]) ? $_POST[$key] : $def;
	}
}

в коде
$check = \input::post('check',false);
и все, никакого неявного поведения, никаких нотисов, код отлично читаем.

[Finesse]

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

[Дмитрий Энтелис]

Finesse: рад что вы это поняли :)

Answer 3

[trevoga_su]

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

Какой треш.. вы откровенно говнокодите, не понимая факта того, что пишите НЕ ПРАВИЛЬНО, не исправляете свои ошибки и при этом еще что-то говорите о чистом коде?

У вас когда в автомобиле масло закончится и об этом будет дан сигнал на консоль - вы тоже проигнорируете эту ситуацию? Или когда у вас батареи потекут - вы также постараетесь это не заметить?

> Недостатки
Все вышеописанные вами недостатки - чудовищное заблуждение и глупость. Тут даже обсуждать нечего.

> Пожалуйста, пишите конкретные случаи, подтверждающие вашу точку зрения.
Никто не будет доказывать, что он прав, а вы - нет. Вы не правы в любом случае. Никому не интересно доказывать человеку, не желающему учиться, что земля круглая, а не держится на 3 черепахах.
Очень трудно разговаривать с человеком, который РАБОТАЕТ программистом и не понимает банальных основополагающих вещей.

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

phpfaq.ru/debug#intro

Answer 4

[index0h]

Большая вероятность неожиданно получить сообщение о предупреждении, что в некоторых случаях нарушает работоспособность сайта.

Не пишите какулю и все будет замечательно))

Больше приходится писать код, меньше сил остаётся на разработку.

Код как правило пишется около 10% времени работы программиста, вы пытаетесь сэкономить ~0.5%, зачем?

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

Глупости.

Answer 5

[Владимир]

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

Answer 6

[Пума Тайланд]

то есть вы считаете использовать не инициализированную переменную в выражении это нормально?

Comments

[Finesse]

Таких ситуаций не возникает.

[Пума Тайланд]

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

Answer 7

[Walt Disney]

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

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

P.S. на продакшене все ошибки и предупреждения надо логировать и разбирать потом.