Я подавлял уведомления в течение некоторого времени без каких-либо проблем, но я начинаю задаваться вопросом, правильно ли я поступаю. Кажется, я не могу найти логической причины, почему я не должен просто подавлять их, но некоторые другие люди, похоже, думают, что подавление их использованием error_reporting – это ужасная вещь, но почему?
Самое близкое к ответу, которое я мог найти, было в этом вопросе, но это еще далеко от ответа, который я ищу. Есть ли какой-то непредвиденный недостаток, чтобы скрыть все уведомления, которые генерирует PHP? Например, чтобы включить переменную из POST-запроса обратно в форму, потому что были ошибки, я просто использовал бы:
<?= $_POST['variable'] ?> Это создаст уведомление PHP. Чтобы исправить это уведомление, я мог бы использовать что-то вроде этого:
<?= isset($_POST['variable']) ? $_POST['variable'] : '' ?>
Но действительно ли это необходимо? Будет ли мой код на самом деле выгоден от этого, а не просто повторять переменную независимо от того, существует она или нет и потенциально создает уведомление PHP? Мне кажется, что возможность игнорировать уведомления – это преимущество использования PHP, так как тогда вам не нужно беспокоиться о том, определена ли переменная или нет, особенно для примера, такого как это, где это, похоже, не имеет значения.
Я также использую способность PHP автоматически изменять тип / литье переменной в зависимости от того, как она используется, и вы часто найдете фрагменты кода, такие как:
for ($i = 0; $i < $limit; $i++) $results[] = $i; // Example
где $results ранее не было определено, но превращается в массив, когда я пытаюсь добавить к нему новый элемент в виде массива. Я предпочитаю делать это так, потому что, если в массив не добавляются результаты, и мне нужно сохранить эту информацию или преобразовать ее в JSON по какой-либо причине, то эта конкретная переменная не будет определена и, таким образом, сохранит дополнительную полосу пропускания, даже если она минута.
$data = stdClass; // For reference, in my case this would be defined before this code $data->results = array(); $limit = 0; for ($i = 0; $i < $limit; $i++) $data->results[] = $i; print json_encode($data); // {"results":[]}
против
$data = stdClass; // For reference $limit = 0; for ($i = 0; $i < $limit; $i++) $data->results[] = $i; print json_encode($data); // []
Вопрос снова: какую реальную выгоду, если таковая имеется, я получаю от исправления ошибок извещения, а не просто для их подавления? Как это может повредить мой код?
С моей точки зрения, вы никогда не должны подавлять ошибки, любые их виды, уведомления или нет. Это может дать вам некоторое удобство прямо сейчас, но по дороге вы столкнетесь с множеством проблем с кодом, когда вы его поддерживаете.
Предположим, у вас есть переменная, которую вы хотите отобразить, как в приведенном выше примере. Да, использование isset немного сложнее, но, возможно, ваше приложение должно обрабатывать специальный пустой случай, тем самым улучшая его. Пример:
if (isset($var)) { echo $var; } else { echo "Nothing is found. Try again later."; }
Если у вас есть только echo $var; и если бы это было общедоступным взглядом, который читал пользователь, они ничего не видели бы там, что может вызвать путаницу. Конечно, это только один частный случай, когда исправление PHP-уведомлений может улучшить ваше приложение.
Это не должно рассматриваться как проблема или неудобство, когда вы заботитесь о уведомлениях в PHP-коде, потому что код должен быть чистым. Я бы предпочел иметь бесплатный код, чем видеть чистый код, когда я его открываю в источнике. Конечно, и то, и другое определенно лучше! 🙂
Опять же, ошибки (даже если они не смертельны) вызовут проблемы в будущем. Если вы уже делаете такие вещи, как echo $var; не проверяя его, это предположение, что существует переменная, даже если вы знаете, что это не так, это просто даст вам привычку предполагать, что вещи существуют и работают . Сейчас это может быть мало, но через некоторое время вы узнаете, что вы вызовете много и много проблем.
Замечания существуют по какой-то причине. Если мы все сделали error_reporting(E_ALL ^ E_NOTICE) в нашем коде, мы просто безответственны для нашего кода. Если вы можете это исправить, тогда почему вы ленитесь и не делаете этого? Конечно, корабль 1.0 с уведомлениями, исправить их позже, это то, что мы все говорим. Но лучше сделать это как привычку, код в первый раз. Если вы потратили 15 минут на написание кода, измученного уведомлениями, а затем потратите 2 часа на более поздний срок разработки, исправив их, почему бы не просто потратить полтора часа на совершенствование кода, как вы его пишете в первую очередь?
Написание хорошего кода должно быть привычкой, а не неудобством. Сообщения об ошибках приведены по какой-либо причине. Уважайте их, исправляйте, и там вы идете, вы ответственный программист.
Вы также проложите путь для будущих сопровождающих вашего кода.
Предположим, что у вас есть уведомление о том, что вы не должны игнорировать. Это уведомление будет скрыто во всех уведомлениях, которые вы обычно игнорируете.
IMHO, предупреждения не следует игнорировать. Вы должны всегда следить за предупреждениями, чтобы предотвратить ошибку. Каждый раз, когда у меня есть уведомление в моем файле журнала, я рассматриваю его как ошибку.
Кроме того, если ваш сайт доступен большому количеству пользователей, вы получите очень большой файл журнала.
По моему опыту, уведомления обычно указывают на хороший шанс, что в вашем коде есть ошибка, обычно в случае, когда вы ожидаете, что определенная переменная будет установлена в определенный момент, но будут случаи, когда это не так, начнем задаваться вопросом, почему какая-то часть вашей страницы не появляется или случайно начинает сбой.
Конечно, компьютеры не все настолько умны, и будут случаи, когда код достаточно ясен, и вам все равно, есть ли какие-либо предупреждения, но для этого @ оператор @ .
Я почтительно не согласен с некоторыми комментариями, которые предполагают, что вы никогда не должны подавлять уведомления. Если вы знаете, что делаете, я думаю, что использование @ очень полезно, особенно для обработки неустановленных переменных или элементов массива. Не поймите меня неправильно: я согласен, что в руках неопытного или неряшливого программиста @ может быть злым. Однако рассмотрим этот пример:
public function foo ($array) { if (isset ($array[0])) { $bar = $array[0]; } else { $bar = null; } // do something with $bar }
функционально идентична
public function foo ($array) { $bar = @$array[0]; // do something with $bar }
но IMHO менее читабельна и больше работы для ввода. В этих случаях я знаю, что существует ровно две возможности: задана переменная или нет. Я не знаю заранее, но я должен действовать в обоих случаях. В этом случае я не вижу ничего плохого в использовании @. Да, вы также можете написать
public function foo ($array) { $bar = isset ($array[0]) ? $array[0] : null; // do something with $bar }
но я нахожу это только немного лучше. Для меня читаемость кода и краткость являются значениями сами по себе, а раздувание кода с помощью isset-тестов просто принципиально для меня немного глупо.
Конечно, если я не ошибаюсь, использование @ занимает немного больше времени для выполнения теста isset-test, но давайте будем честными: насколько наш код действительно критичен по производительности? В цикле, который выполняется в bazillion раз, я бы, вероятно, использовал isset вместо этого, но в большинстве случаев он не имеет никакого значения для пользователя.