コンパイラの警告

多くのコンパイラには、潜在的なランタイム、ロジック、およびパフォーマンスエラーについてプログラマに警告する警告メッセージがあります。ほとんどの場合、すぐに修正できますが、修正不可能な警告はどうでしょうか。

修正不可能な警告にはどのように対処しますか？コードの一部を書き直しますか、それとも「長く、ハックレスな方法」で書き直しますか、または警告をすべて無効にしますか？ベストプラクティスは何ですか？

他の人のコードを編集していて、彼のコードに警告がある場合はどうなりますか？

次に例を示します。MozillaクラスのブラウザがjQueryに多数のJavaScript警告を検出したため、jQ開発者が修正しないのはなぜですか？jQueryに貢献する場合、それらを修正しますか？

いくつかの警告は通常無視しても安全ですが、そうすると、時間が経つにつれて増え、ノイズに隠れているために本当に重要な警告が1つも見逃されるほど多くなります。

警告をすぐに修正します（コンテキストに関係がないと思われる場合は、個々のルールを無効にすることが含まれる場合があります）。

私の意見では、あなたは自分自身に厳格であるべきです。コンパイラは、言語の専門家によって書かれています。何かが少し気味が悪い（コードのにおいがする）と報告している場合は、コードを確認する必要があります。

エラーや警告なしでコンパイルするコードを書くことは完全に可能です。

CとC ++で書いていたとき、コンパイラにとって意味がわからないときを知りたかったので、できる限り厳しい設定を有効にしました。キャストと戻り値のチェックが終わったら、コードができる限り正確だったので嬉しいです。

私は時折、警告を発するコードを他の誰かから入手していました。ソースをチェックすると、Cの優れたプログラミング手法であるものを無視し、コードが脆弱になっていることがわかりました。

だから、私は厳格さを可能にし、物事を修正するのに時間をかける正当な理由があると思います。それ以外のことを行うことはずさんです。警告をオフにする同僚がいた場合、私は彼らと一緒に時間を費やし、マネージャーがそれが本当に悪いことである理由を説明します。

警告を修正します。それらを無視して蓄積させると、実際に重要な何かを見逃す可能性があります。

一般に、新しい警告がより多く表示されるように、コンパイラをサイレントにするように努力する必要があります。これらの警告は微妙なバグを示している可能性があるため、それに応じて処理する必要があります。

他の人のコードの修正に関しては、職場の文化とコードの現在の状態の両方に強く依存します。完全な再テストサイクルをトリガーする場合、テストフェーズの後半や本番でのコードのように、コードを変更することはできません。

上司に聞いて、それに応じて行動してください。

コンパイラの警告が表示されるたびに、停止して、それが本当に顧客のサイトで顔を爆破するのを待っている問題なのか、無視できるものなのかを考えなければなりません。さらに悪いことに、TODAYを無視できるのは、一見無関係なコードの変更がSomewhere Elseの後に数年後に顧客のサイトで爆発するかもしれません。

警告を修正します。限目。それは、それがリスクではないことを証明するために必要なだけの説明のページで、それらのすべてを一つずつ文書化することです。リスクでした。

一般に、ビルドに警告がないようにします。警告には理由があり、多くの場合、非常に現実的な問題を示しています。コンパイラーの警告を無視する習慣に陥ると、最終的にビルドには大量の警告が表示され、会社に多大な損害を与える壊滅的な問題によって引き起こされる警告を逃すことになります。一方、プログラムが通常警告なしでコンパイルされる場合、新しい警告はすべてすぐに通知され、すぐに対処できます。

そうは言っても、コンパイラーは、ほとんど意味がなく、簡単に修正できない警告を表示することがあります。TI DSPの開発環境であるTI CodeComposerを使用して、毎日このような状況に直面しています。Visual Studioで警告なしでコンパイルするC ++コードがありますが、それは単にCodeComposerで奇妙な警告を引き起こします。単純にTIの標準C ++のサポートがより良い可能性があるからです。さいわい、CodeComposerを使用すると、特定の警告を個別に無効にできます。これは、警告を生成するコードを修正する方法がない場合に行うことです。

私の場合、警告はPyLintツールから出され、コメントに特別なテキストを追加することで特定の行の警告を無効にできます。

ほとんどの場合、私はそれをしません。PyLintは通常正しいため、ほとんどの場合、PyLintが提案するものに従うようにコードを変更します。ただし、一般的には悪い考えですが、特定のコンテキストで意味をなす構成要素は嫌いです。たとえば、考えられるすべての例外をキャッチすると文句を言います。通常、その正しい、それは悪い考えです。ただし、場合によっては、詳細を含むエラーレポートを自分に送信するなど、すべての例外をキャッチしたいことがあります。

だから：ほとんどすべての場合、ハックを取り除く。ハッキングが本当に正当化されたら、PyLintに問題がないことを伝えるコメントを追加します。

厳密性の利点のいくつかは、他の回答では明確に述べられていません。

1. 簡単に修正できるすべての警告が修正されると、残りの重要/関連する警告が表示される可能性が高くなります。
2. 関連する警告が発見され、期限内に（リリース前に）処理される場合、バグを回避できるため、エンドユーザーの満足度が向上します。
3. 通常、警告を解決すると、コードのメンテナンス性とシンプルさが向上します（例：常に真である条件を排除する）
4. 警告の量が0に近づくと、チームのゼロ警告ポリシーに同意しやすくなります。これはCIシステムで非常に簡単に自動化できます。
5. コンパイラの警告を解決するとき、プログラムコードの理解が深まり、実装に関する有用な洞察につながる可能性があります（たとえば、他のバグを発見したり、コードをさらに開発する方法のアイデアを得る）
6. ビルドの速度が向上し、毎日の生産性が向上します。IDE/コンパイラーは管理およびレポートの問題が少ないため、コンパイルが高速になります（これは数千の警告のコンテキストにのみ関連します）。

特定の種類の警告には言語固有の違いがあります。トピックについて考えて議論し、完全に役に立たないと感じる場合は個々の警告を無効にして、厳密性を達成することが重要だと思います。これは私のキャリアのいくつかのチームで達成されました。トピックに関する私の経験の詳細

警告とエラーは、コンパイラーがプログラマーに「あなたが書いたものが意味をなさない」ことを伝えるために使用するメッセージです-それらの違いは、警告があれば、コンパイラーはプログラマーの意図について推測することをいとわないということですエラーが発生すると、コンパイラは推測すらできません。

コンパイラエラーは、（私が言うつもりはありません対処されます固定）が、あまりにも頻繁に、プログラマ（でも経験のあるもの）が警告を無視します。警告を無視することの問題は、コンパイラが間違って推測することがあり、1000以上の警告メッセージがある場合は、コンパイラが間違って推測していることを示す警告メッセージを見逃しやすいことです。

社会学的な観点から、多くの警告メッセージがあるプログラムはBroken Windowsです。