20

私はかなり長い間通知を何の問題もなく抑制してきましたが、私は正しいことをしているのだろうかと思い始めています。それらを単に抑制するべきではないという論理的な理由を見つけることができないようですが、他の人々は、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

4 に答える 4

23

私の見解では、エラー、あらゆる種類のエラー、通知の有無にかかわらず、決して抑制すべきではありません。今は便利かもしれませんが、将来的には、コードを保守しているときに、コードに関して多くの問題に直面することになります。

上記の最初の例のように、エコーアウトしたい変数があるとします。はい、issetの使用は少し複雑ですが、アプリケーションで特別な空のケースを処理して、エクスペリエンスを向上させる必要があるかもしれません。例：

if (isset($var)) {
    echo $var;
} else {
    echo "Nothing is found. Try again later.";
}

あなたが持っているだけecho $var;で、これがユーザーが読んでいる公開ビューである場合、ユーザーはそこに何も表示されないため、混乱が生じる可能性があります。もちろん、これはPHP通知を修正することでアプリケーションを改善できる特殊なケースの1つにすぎません。

コードはクリーンであると想定されているため、PHPコードで通知を処理する際に、トラブルや不便を感じないようにする必要があります。ソースで開いたときにクリーンなコードが表示されるよりも、通知のないコードが必要です。もちろん、どちらも間違いなく優れています！:)

繰り返しになりますが、エラーは（致命的ではない場合でも）将来的に問題を引き起こします。あなたがすでにecho $var;それをチェックせずに何かをしているなら、それは変数が存在するという仮定です、たとえそれがそうでないかもしれないと知っていても、それはあなたに物事が存在して働くと仮定する習慣を与えるでしょう。これは今は小さいかもしれませんが、しばらくすると、自分自身に多くの問題を引き起こすことがわかります。

通知には理由があります。私たち全員が自分error_reporting(E_ALL ^ E_NOTICE)のコードでやったとしたら、私たちは自分のコードに対して無責任であるだけです。あなたがそれを修正することができるなら、なぜあなたは怠惰でそうしないのですか？確かに、1.0を通知付きで出荷し、後で修正します。それが私たち全員の言うことです。しかし、それを習慣として行う方が良いです。最初は完璧なコードを作成してください。通知に悩まされているコードを書くのに15分を費やし、その後の開発時間でそれらを修正するのに2時間を費やす場合、最初にコードを書くときに1時間半かけてコードを完成させてみませんか？

良いコードを書くことは、不便ではなく習慣であるべきです。エラーメッセージには理由があります。それらを尊重し、修正すれば、責任あるプログラマーになります。

また、コードの将来のメンテナへの道を開きます。

于 2011-08-19T01:59:16.323 に答える
4

無視してはならないという通知があるとします。この通知は、通常無視するすべての通知に隠されます。

私見、警告は無視されるべきではありません。バグを防ぐために、常に警告に注意する必要があります。ログファイルに通知があるたびに、それをバグのように扱います。

また、多くのユーザーがサイトにアクセスすると、非常に大きなログファイルが作成されます。

于 2011-08-19T01:59:21.673 に答える
3

私の経験では、通知は通常、コードのどこかにバグがある可能性が高いことを示しています。通常、特定の変数が特定の時点で設定されることを期待しているが、そうでない場合もあります。ページの一部が表示されない、またはランダムにクラッシュし始めるのはなぜか疑問に思い始めます。

もちろん、コンピューターはそれほど賢いわけではなく、コードが十分に明確で、警告があるかどうか気にしない場合もありますが、それが@オペレーターの目的です。

于 2011-08-19T02:06:19.677 に答える
3

私は、通知を決して抑制してはならないことを示唆するコメントのいくつかに敬意を表して同意しません。何をしているのかがわかっている場合は、@を使用すると、特に未設定の変数や配列要素を処理する場合に非常に便利だと思います。誤解しないでください。経験の浅いプログラマーやずさんなプログラマーの手には、@が悪である可能性があることに同意します。ただし、次の例を検討してください。

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
}

しかし、私見では読みにくく、入力する作業が多くなります。このような場合、変数が設定されているかどうかという2つの可能性があることを私は知っています。事前にはわかりませんが、どちらの場合も進めなければなりません。その場合、@を使用しても問題はありません。はい、書くこともできます

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

    // do something with $bar
}

しかし、私はそれがほんのわずかに良いと思います。私にとって、コードの可読性と簡潔さはそれ自体が価値であり、私にとって原則から外れたisset-testsでコードを肥大化させることは少しばかげています。

もちろん、私が間違っていなければ、@を使用すると、そのisset-testを実行するのに少し時間がかかりますが、正直に言うと、コードのどれだけが本当にパフォーマンスに重要なのでしょうか。何億回も実行されるループでは、おそらく代わりにissetを使用しますが、ほとんどの場合、ユーザーには違いはありません。

于 2014-10-06T15:43:16.447 に答える