4

これを行う正当な理由を 1 つ教えてください

if( isset($_GET['key']) && ($_GET['key'] === '123') )
{...

これの代わりに

if( @$_GET['key'] === '123' )
{...

私はこの非常に具体的なコードケースを求めていますが、一般的ではありません!

次の理由は歓迎されません。

  • "を使用@すると、アプリケーションの速度が数ナノ秒低下します。これは、(エラーが抑制されている場合でも) とにかくエラーが作成されるためです。 " まあ、私はより遅いコードを好みますが、より読みやすくします。
  • 「使用@は悪い習慣です。」一般的には正しいかもしれませんが、この場合は信じられません（さらに、悪い習慣はコンテキストに依存する可能性があります.PHPマニュアルでは、特定の状況でのfopen使用を提案しているように機能します。エラー/を参照してくださいhttp://www.php.net/manual/en/function.fopen.php@の例外)
4

3 に答える 3

5

パフォーマンスへの影響は、実際にはこの例に対する最良の議論ではありません。これが問題かどうかを判断するには、独自のアプリケーションでパフォーマンスを測定する必要があります。多数のチェック項目が設定されていない場合や、このようなチェックをループ内に配置すると、速度が低下する可能性が高くなります。

演算子の使用に関連する主な問題@は、それがコードの慣習になる可能性が高いことです。そのため、例は無害に見えるかもしれませんが、後で自分自身またはチームが以下を使用していることに気付くかもしれません。

if( @IsAvailable() ) {

そして、エラーの抑制により、予期していなかった実際のエラーと実際に発生したエラーが隠され始めます。例外情報がまったく得られないため、何が起こったのかわかりません。

于 2013-02-22T15:32:09.747 に答える
1

ウェブサイトやアプリが 1 日に数万または数十万 (またはそれ以上) のリクエストを受け取り始めたときに、アプリケーションの速度がどれだけ低下するかを考えてみてください。標準としてエラーを抑制している場合、おそらくすべてのリクエストに対して数十のエラーが発生します。突然、サイトが思ったよりも著しく遅くなります。

これに加えて、開発中に実際に認識したいエラーを抑制してしまう可能性があります。

于 2013-02-22T15:26:59.517 に答える
0

パフォーマンスの問題を引数に取らなければ、問題ありません。しかし、すべての場合である必要はありません。なぜなら、@ は、考えもしなかったエラーも含め、考えられるすべてのエラーを抑制するからです。ただし、この場合、抑制したいエラーが他にある可能性はないようです。

値を読み取る前に isset() を実行することは非常に醜く、私もそれを書くのは好きではないことに同意します。しかし、ステートメントの前に @ を挿入するのは見苦しいようです。長いコードでは可読性が低下する可能性があります。

良いニュースは、PHP 7 以降、はるかに優れた方法である null 合体演算子??を使用できるようになったことです。次のように機能します。

if($_GET['key'] ?? '' === '123' ) {}

これは基本的にこれに代わるものです：

$result = isset($value) ? $value : $anotherValue;

今、あなたは使用することができます

$result = $value ?? $anotherValue;
于 2016-02-23T13:59:40.110 に答える