私たちのプロジェクト マネージャーは最近、すべてのコンパイラ警告を削除するように開発者に要求するポリシーを設定しました。いくつかの警告は本当に簡単に削除できることを理解していますが、一部の警告はそれほど簡単ではありません。そのため、一部の開発者は、目標を達成するためにあらゆる方法を使用します。たとえば、明示的なキャストを使用して、double を float に、float を int に、signed を unsigned にキャストするなどです。私たちのコード ベースは非常に大きいため、30 ~ 50 人の開発者が 20 年以上にわたって取り組んできたことを考えると、この努力がどれほどのものかは本当に疑問です。メリットがあれば、本当に助かります。アドバイスや議論をしてくれる人はいますか? 私たちのプロジェクトは C++ を使用しています。
3 に答える
コンパイラの警告を無視すると、「実際の」警告も無視されます。大量の警告が表示されたプロジェクトに出くわした回数は数えきれませんが、それはほんの少しの注意で、非常に微妙なバグの束とともに削除されました。if での偶発的な代入、スイッチでの偶発的なフォールスルー、またはデフォルトではない、偶発的な ; forループの最後、意図しない型キャストなど。警告には理由があります-それらを使用してください。はい、非常にペンダント的なものもありますが、少し作業するだけで、後で頭痛の種が大幅に軽減されます.
警告をきれいにして、きれいに保ちます。あなたはより良いコードを書くでしょう。
大規模なプロジェクトですべての警告を修正するのは非常に難しい場合があります。また、一部のコンパイラは、「警告すべき正しいこと」についてかなりあいまいな感覚を持っています。
警告を修正することは間違いなく良いことです。しかし、それは正しい方法で行われるべきです - そして時々、正しいことは単にその警告を無効にすることです.
いくつかの本当に厄介なものは「未使用のパラメーター」です。この関数が 2 つのパラメーターで呼び出されているとインターフェイスが判断した場合、この特定の実装がそれらのパラメーターを使用していないため、1 つしか使用しない (または何も使用しない) 場合は、警告を修正するのは難しい[もちろん、変数の名前を削除する(またはコメントとして入れる)ことができます]。
同様に、コンパイラが非常にうるさいため、正しいことが不可能な場合があります-関数の最後に戻りがないために「すべてのパスが戻りにつながるわけではない」というケースがあり、最後に戻りを追加すると関数の、「到達不能なコード」と表示されています-まあ、どうしますか?これは、(コードのそのセクションについて)関連する警告を無効にすることが正しいことです。
複数のコンパイラでコードをコンパイルする必要がある場合はさらに悪化します。コンパイラで「良い」ものが別のコンパイラでは警告になり、その警告の修正が次のコンパイラで警告に変わることがあります。解決するのが難しい。
警告に対処するための戦略を立て、削除したいものを削除し、無効にしたいものを無効にしたら、「警告をエラーとして処理する」ように製品を構築することをお勧めします。
ほとんどの場合、警告はプログラマーにとって「良い」ものであり、無視すべきではありません。しかし、「自分が何をしているか分かっている、コンパイラを黙らせろ!」という時があります。もちろん、ほとんどの場合、それらはキャストなどを適用することで修正されますが、それが問題を修正する正しい方法である場合は、それを行う必要があります。
いいえ。すべての警告ではなく、いかなる手段でもありません。
すべての警告ではありません。一部のコンパイラは、文体的または不正確な警告を実装しています。実際の問題から注意をそらすため、これらの警告を無効にする方がよい場合がよくあります。
決してではありません。警告は、疑わしいことが起こっていることを通知するためにコンパイラによって使用されます。たとえば、最も興味深い警告は、考えられる未定義の動作を通知します。目的は、コンパイラーをなだめるためだけに警告を削除することではなく、動作が明確に定義されていることを確認することであり、それが明確に定義されていない場合はそうする必要があります。
私のアドバイスは、最初にアクティブ化された警告のセットを確認し、役に立たない警告を取り除くことです。次に、残された警告が何であるかを理解し、それぞれに対処するための最良の方法について合意します(定義された動作を取得することを目的としています)。そして最後に、コードベースで作業できるようになります。