通常、私はE_ALLPHPが自分のコードについて言っていることを確認して、コードを改善しようとしています。
エラー定数に気づきましたE_STRICTが、使用したことも聞いたこともありません。これは開発に使用するのに適した設定ですか？マニュアルには次のように書かれています。
実行時の通知。PHPにコードの変更を提案させて、コードの最高の相互運用性と上位互換性を確保できるようにします。
だから私は私が最高のレベルを使用しているのか、それとも一緒に最高のerror_reportingレベルを使用しているのだろうかと思っていますか？それとも、私がまだ学んでいない他の組み合わせはありますか？E_ALLE_STRICT
PHP 5 では、 でカバーされているものは でカバーされE_STRICTていないE_ALLため、ほとんどの情報を取得するには、それらを組み合わせる必要があります。
error_reporting(E_ALL | E_STRICT);
PHP 5.4 では、E_STRICTに含まれるE_ALLので、 だけを使用できますE_ALL。
使用することもできます
error_reporting(-1);
これにより、常にすべてのエラーが有効になります。次のように意味的に正しいのはどれですか。
error_reporting(~0);
php.ini で次を使用します。
error_reporting = E_ALL | E_STRICT
また、 Xdebugをインストールする必要があります。明るい色でエラーを強調表示し、有用な詳細情報を出力できます。
無害であっても、コードにエラーや通知を入れないでください。
私の意見では、開発段階でエラー報告レベルを高く設定するほど、より良い結果が得られます。
ライブ環境では、わずかに (ただしわずかに) 削減されたセットが必要ですが、ユーザーが見ることができない場所にログを記録する必要があります (私が好むsyslog)。
http://php.net/error_reporting
E_ALL | E_STRICT5.2.0 より前の PHP での開発用。
5.2 では が導入されE_RECOVERABLE_ERROR、5.3 ではE_DEPRECATEDおよびが導入されE_USER_DEPRECATEDます。これらのバージョンのいずれかを実行している場合は、おそらくそれらをオンにする必要があります。
マジック ナンバーを使用したい場合は、error_reporting値をかなり高い値に設定するだけで済みます。2^n-1たとえば、です。16777215これにより、 の間のすべてのビットがオンになります1..n。しかし、マジックナンバーを使うのは良い考えではないと思います...
E_ALL私の意見では、PHP は実際にはすべてではなかったので、ボールを少し落としました。しかし、どうやらそれはPHP 6で修正される予定です...
新しい PHP バージョンでは、E_ALL に含まれるエラーのクラスが増えています。PHP 5.3 以降、E_ALL には E_STRICT以外のすべてが含まれます。PHP 6 では、それも含まれると言われています。これは良いヒントです。表示されるエラー メッセージは、少ないよりは多い方がよいでしょう。
E_ALL に含まれるものは、オンライン マニュアルのPHP 定義済み定数ページに記載されています。
個人的には、E_STRICT を使えば大した問題ではないと思います。特に、PHP の将来のバージョンで壊れる可能性がわずかにあるスクリプトを作成できなくなる可能性があるため、害はありません。一方、場合によっては、特に急いでいる場合など、厳密なメッセージがうるさすぎることがあります。デフォルトでオンにして、面倒になったらオフにすることをお勧めします。
使用することができますerror_reporting = -1
それは常にすべてのビットで構成されます（E_ALLにない場合でも）
このコードの長期的なサポート計画によっては、デバッグをE_STRICT有効にしてデバッグを行うと、コードが遠い将来も機能し続けるのに役立つ場合がありますが、日常的な使用にはおそらくやり過ぎです。E_STRICT心に留めておくべき重要な点が 2 つあります。
E_STRICTエラーは実行時ではなくコンパイル時に生成されます。( php.iniE_ALL経由ではなく) コード内でエラー レベルを上げている場合、とにかくエラーが表示されない可能性があります。E_STRICTE_STRICTは PHP 6 に含まれていますE_ALLが、PHP 5 には含まれていません。サーバーを PHP6 にアップグレードし、E_ALL上記の #1 で説明したように構成するE_STRICTと、追加の変更を行わなくてもエラーが表示されるようになります。error_reporting について厳密に言えば、解析エラーや一般的な不具合 (条件の代入など) を自動的に表示する IDE を使用することを強くお勧めします。
Zend Studio for Eclipse では、この機能がデフォルトで有効になっています。この機能を使い始めて以来、エラーが発生する前にキャッチするのに大いに役立っています。
たとえば、$GLOBALS変数にデータをキャッシュしていた次のコードがありましたが、うっかり$_GLOBALS代わりに書き込んでしまいました。データがキャッシュされることはなく、Zend が「これ$_GLOBALSは 1 回しか表示されないため、エラーである可能性があります」と言わないかどうかもわかりませんでした。
ini_set（ "display_errors"、 "2"）; ERROR_REPORTING（E_ALL）;