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