Можно ли скрывать / скрывать уведомления PHP? - PullRequest
Новая
       6

Можно ли скрывать / скрывать уведомления PHP?

19 голосов
/ 19 августа 2011

Я довольно долго подавлял уведомления без проблем, но начинаю задумываться, правильно ли я поступаю.Кажется, я не могу найти никакой логической причины, по которой я не должен просто подавлять их, но некоторые другие люди, кажется, думают, что подавлять их с помощью 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);
// []

Снова вопрос: какую реальную выгоду, если таковая имеется, я получаю, исправляя ошибки уведомления, а не просто подавляя их?Как это может повредить моему коду?

Ответы [ 4 ]

24 голосов
/ 19 августа 2011

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

Предположим, у вас есть переменная, которую вы хотите вывести, как указано выше.первый пример.Да, использование 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 часа на последующее время разработки исправления их, почему бы просто не потратить полтора часа на совершенствование кода, как вы его пишете?

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

Вы также проложите путь для будущих разработчиков вашего кода.

4 голосов
/ 19 августа 2011

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

ИМХО, предупреждения не следует игнорировать. Вы должны всегда заботиться о предупреждениях, чтобы предотвратить ошибку. Каждый раз, когда в моем журнале появляется уведомление, я воспринимаю его как ошибку.

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

3 голосов
/ 19 августа 2011

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

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

2 голосов
/ 06 октября 2014

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

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
}

но ИМХО менее читабельно и больше работает для ввода. В таких случаях я знаю, что существует ровно две возможности: переменная установлена ​​или нет. Я не знаю заранее, но я должен действовать в обоих случаях. Я не вижу ничего плохого в использовании @ в этом случае. Да, вы также можете написать 

public function foo ($array) {
    $bar = isset ($array[0]) ? $array[0] : null;

    // do something with $bar
}

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

Конечно, если я не ошибаюсь, использование @ занимает чуть больше времени для выполнения этого isset-теста, но давайте будем честными: какая часть нашего кода действительно критична для производительности? В цикле, который выполняется несколько раз, я бы, вероятно, вместо этого использовал isset, но в большинстве случаев это не имеет значения для пользователя.

...