C / C ++コンパイラの警告：すべてのコードをクリーンアップして削除しますか、それともそのままにしますか？
私は他の人から更新するコードを与えられた多くのプロジェクトに取り組んできました。多くの場合、私はそれをコンパイルして、約1,000以上のコンパイラ警告を受け取ります。コンパイラの警告が表示されると、汚れた感じがするので、最初のタスクはコードをクリーンアップしてすべて削除することです。通常、初期化されていない変数など、約12の問題があります。
なぜ人々がそれらを残し、警告のない完全にクリーンなコンパイルを持っていないのか理解できません。私は何かが足りないのですか？それらをそのままにしておく正当な理由はありますか？共有するホラーストーリーはありますか？
警告をクリーンアップします。あなたが無害であると知っているものでさえ（そのようなものが存在する場合）、コードをコンパイルする人にあなたの悪い印象を与えるでしょう。
これは、他の誰かのコードに取り組む必要がある場合に私が探す「臭い」兆候の1つです。
実際のエラーや潜在的な将来の問題ではない場合、それはだらしのない兆候です
実際の問題を示していない場合でも、クリーンアップしてください。そうしないと、doesが実際の問題を示しているという警告が表示された場合、すべてのノイズを通してそれを確認することはできません。
私の仕事では、警告をエラーとして扱うコンパイラ設定がオンになっています。したがって、警告はありません。そうしないと、コンパイルされません:)
すべての警告を削除するのが最善であることに同意します。何千もの警告が表示される場合は、修正を優先する必要があります。
コンパイラを最低の警告レベルに設定し始めます。これらの警告は最も重要なはずです。それらが修正されたら、警告レベルを上げて、最高の警告レベルに達するまで繰り返します。次に、警告がエラーとして扱われるようにコンパイルオプションを設定します。
無視しても安全だと思われる警告を見つけた場合は、調査を行って理論を検証してください。その後、それを無効にし、可能な限り最小限の方法でのみ無効にします。ほとんどのコンパイラには#pragmaファイルの一部のみの警告を無効/有効にできるディレクティブ。 Visual C++の例を次に示します。
typedef struct _X * X; // from external header, not 64-bit portable
#pragma warning( Push )
#pragma warning( disable: 4312 ) // 64-bit portability warning
X x = reinterpret_cast< X >( 0xDDDDDDDD ); // we know X not 64-bit portable
#pragma warning( pop )
これにより、1行のコードの警告のみが無効になることに注意してください。この方法を使用すると、将来的にコードの簡単なテキスト検索を実行して変更を加えることもできます。
または、通常、単一のファイルまたはすべてのファイルに対して特定の警告を無効にすることができます。私見これは危険であり、最後の手段にすぎません。
それらをクリーンアップします 可能なら。マルチプラットフォーム/マルチコンパイラコードベース（6つの異なるコンパイラを備えた7つの異なるOSでコンパイルされたコードベースで作業しました）では、常に可能であるとは限りません。コンパイラがただの場合を見てきました 違う （Itanium上のHP-UX aCC、私はあなたを見ています）、しかしそれは確かにまれです。他の人が指摘しているように、このような状況では警告を無効にすることができます。
多くの場合、このバージョンのコンパイラでの警告は、次のバージョンでエラーになる可能性があります（gcc 3.xから4.xにアップグレードする人は、これに精通している必要があります）。今すぐクリーンアップしてください。
一部のコンパイラは、特定の状況下で問題となる非常に便利な警告を出力します。VisualC++ 2005および2008は、64ビットの問題について警告することができます。これは、今日では大きなメリットです。 64ビットに移行する計画がある場合は、これらの種類の警告をクリーンアップするだけで、ポート時間が大幅に短縮されます。
コードに警告を残したり、警告をクリーンアップすることが不可能な場合があります（ただし、可能なものは削除します）。例えば：
- 作業中の作業があり、さらに作業や注意が必要であることがわかっている場合は、これが適切である可能性があることを示す警告を残しておきます。
- / clrを使用してC++をコンパイルしている場合、ネイティブコードが生成される原因となるものについていくつかの警告があります。コードベースを機能的に変更できない場合、これらすべての警告を抑制するのは面倒な場合があります
- 修正の内容がわからない場合の警告のクリーンアップ。私はこれをPC-Lint警告で数回実行し、バグを導入することになりました。変更の正確な効果がわからない場合（例：警告を排除するためのCスタイルのキャスト）、それを行わないでください。警告を理解するか、コードをそのままにしておくことをお勧めします。
とにかく、それらは警告を残すことが適切であるかもしれない私の頭の上のインスタンスです。
最悪の部分は、新しいコードを書くときに、誤って警告を追加したかどうかを知るのが難しいことです。とにかく無視するだけの警告がたくさんあるからです。
それらをすべてクリーンアップする際の問題は、あなたが持っているかもしれないし、持っていないかもしれないのに時間がかかるということです。しかし、はい、一般的にはできるだけ多くのクリーンアップを行う必要があります。
警告を修正する時間がないためにコードに警告を残すことは、朝に十分な時間がないために歯を磨かないようなものです。それはコード衛生の基本的な問題です。
常に警告をクリーンアップしてください。警告に問題がないことがわかっている特定のケースがある場合は、そのインスタンスに対してのみ警告を抑制してください。
一部の警告は無害である可能性がありますが、ほとんどはコードの実際の問題を示しています。
すべての警告をクリーンアップしないと、警告リストが増え続け、実際の問題のケースは警告ノイズの海で失われます。
本当に優れたプログラマーの特徴の1つは、悪いコードが彼らに吐き気を催させることです。
私はすべてのコードをコンパイラーだけでなく、IDEの内部もかなりうるさいレベルに設定するようにしています。よくわかっている場合は、警告インスタンスを抑制する必要がある場合があります。ツールよりも優れていますが、少なくともそれはドキュメントとしても機能します。
私は常にすべての警告を有効にし、警告がある場合はビルドを停止するようにプロジェクトを設定します。
警告がある場合は、それぞれをチェックして問題がないことを確認する必要があります。これを何度も繰り返すのは時間の無駄です。これを行わないと、コードにエラーが忍び寄ることになります。
警告を削除する方法はいくつかあります（例：#pragma argsused）。
コンパイラに作業を任せます。
私は、警告が不安定、クラッシュ、またはメモリ破損を引き起こす多くの組み込みシステムを使用してきました。警告が無害であることがわかっていない限り、対処する必要があります。
警告はバグとして扱われるべきであり、扱われるべきです。警告を取り除くのに十分なコーディングができない場合は、おそらくコーディングすべきではありません。私のグループでは、すべての警告を強制的にエラーにすることを決定しました。これでこの議論は完全に終わり、IMHOはコードの品質を向上させます。
警告は嫌いです。可能な限り削除します。
時々、仕事を終えるプレッシャーにさらされているとき、私はそれらのいくつかを残します。私はめったにそれらを残しません。私はあなたのように感じます、残っているものがあれば汚いです。
私が取り組んでいるコードベースには4000を超える警告があります。それらのいくつかは正当な問題です。私たちは、それらを修正したり、他の壊れたものをリファクタリングしたりする時間が与えられることはありません...部分的に、これはコードが非常に古く、標準化されたC++よりも古いためです。 VC++ 6でのみコンパイルできます。
常にすべての警告をクリーンアップするか、必要に応じて明示的に抑制してください。警告のデフォルト設定は、コンパイル時に可能な限り高くする必要があります（たとえば、VSのレベル4）。
私が現在維持しているコードを作成した上司。彼はコンパイラフラグを使用して、剥奪の警告を非表示にします。
時間があるときは、できることを調べて片付けます。
私はかなり高レベルの警告を含むコードをコンパイルし、それらをすべてクリーンアップしようとします。ただし、「符号付き/符号なしの比較」警告は修正する必要がありますが、気にすることはできません。
短いバージョン：g ++では、「-Wextra -Wno-sign-compare」を使用して、すべてのメッセージを削除します。