c# - 警告を処理するためのベストプラクティス

Question

私が現在取り組んでいるプロジェクトは、ビルドされるたびに 30 以上の警告を生成します。それらはプロジェクトの最初から無視されていました。警告に関するポリシーの欠如が原因だと思います。

通常、これをどのように処理しますか? それらを完全に無視しますか？それらを一度にすべて修正してみてください (これには時間がかかります) ? それとも、途中で少しずつ修正しますか？

score 15 · Accepted Answer

それらは 30 個しかないので、修正するだけで 2 時間かかります。

締め切りがこれらの警告の修正に取って代わると言う人には、私は完全に同意しません。今問題を修正した場合よりも、ポストコードの完了段階で問題を解決するために後で時間を浪費することになります。あなたのマネージャーを無視してください、彼はおそらく彼の上司に似合うことを望んでいる馬鹿です. 初期の品質と正しい設計は、彼の恣意的な期限よりも重要です (合理的な範囲内で)。そもそも警告があるということは、誰かがコードをずさんに扱っていたことを意味します。警告が存在する領域が正しいことを再確認してください。

コード分析を使用している場合、または C/C++ を作成している場合、警告が実際には有効でない場合があります。その場合、それらをプラグマアウト (C/C++) または System.Diagnostics.CodeAnalysis.SuppressMessage します。これは、VS2008 から自動的に行うことができます。

コード分析以外では無効な .net 警告は見たことがありません。

score 10 · Accepted Answer

警告をエラーとして扱う設定でビルドすることを強くお勧めします。もちろん、これによりプロジェクトのビルドが停止しますが、妥当なエラーポリシーを強制する唯一の方法です。

それが完了したら、警告を調べて、合理的な決定を下すことができます。無害で気にしない警告がいくつかある可能性があるため、これらを無視する警告のリストに追加してください。それらの残りを修正します。今すぐすべてを修正する時間がない場合は、#pragma (または C# に相当するもの) を追加して、すべてのファイルで発生する特定の警告を無視し、これらのそれぞれについてバグを報告して、後で確実に対処できるようにします。

score 9 · Accepted Answer

私たちの開発チームでは、各人が金曜日のビールの前に警告を片付ける必要があります。警告を修正しない場合は、ビールはありません。意外と良い刺激になります。

score 4 · Accepted Answer

昨年の秋、私は100の無視された警告を持つ新しい5,000行のJavaサブシステムを継承しました。ここにいる他の回答者と同様に、私のポリシーはすべての警告を修正することであり、そうすることで、100のうち3つが真のプログラミングエラーであることがわかりました。警告には理由がありますので、無視せずに修正してください。

score 4 · Accepted Answer

ほとんどのプログラマーは、各コンストラクトを作成した後、コードが正しくビルドされるかどうかを確認するために定期的にコードをビルドします。これは、警告にフラグが立てられるときです (VB では、バックグラウンドビルドによってもフラグが立てられます)。

ビルドごとに警告を修正することをポリシーにしています。また、警告にフラグを立てるチームからのコードも受け入れません。「許容できる」警告の種類はごくわずかです。

そのため、後でまとめて修正するのではなく、フラグが立った時点で修正するというのが私のポリシーです。余談ですが、自分のコードが警告のフラグを立て始めると、自分の基準を満たしていないコードを書いていることを自責します。

score 3 · Accepted Answer

すべての警告を修正するか、明示的に無効にする必要があります (コンパイラディレクティブまたはそれを排除するコード構造を使用)。
警告を無効にせずに無視すると、すべての警告が無意味になります。いくつかの「問題ない」警告があることはわかっているのに、わざわざリストを見る必要はありません。

さらに、最高の警告レベルでコンパイルし、「警告をエラーとして扱う」ことを強くお勧めします (ただし、これはコンパイラによって行われます)。コンパイラがこの設定をサポートしていない場合は、ビルドスクリプト/プロセスの一部として出力/戻り値を確認することで、とにかく強制してみてください。

score 1 · Accepted Answer

プログラミング中は、コンパイル時（悪の実行時エラー）では捕捉されない多くの問題が発生します。そのため、コンパイラはすべての問題（別名エラー）を見つけることができません。場合によっては、問題があるかもしれないと彼は言うだけですが、私にはよくわかりません。確認してください（別名警告）。したがって、警告を確認して修正し、続行してください。

まれに、あなたは自分が何をしているのかを本当に知っていて、ただ考えているだけです。私はこの警告を知っていますが、このコードは正しいので、もう気にしないでください。これらの（非常にまれな）ケースでは、次のように言及されている行をカプセル化することができます。

// Why you think this warning should be disabled at this point
#pragma warning disable xxx
/// ... some code ...
#pragma warning restore xxx

続行すると、コンパイラはもう言及しません。

したがって、すべての警告を確認して修正してください。再プログラムするか、この警告を一時的に無効にします。

PSプロジェクト設定内で警告を無効にしないでください。この場合、グローバルに無効にします（したがって、将来作成されるコードの場合もあります）。また、無効にした理由についてコメントを追加することもできません。

score 1 · Accepted Answer

ベストプラクティスは、それらをまとめて修正することです。時間がかかるように思えるかもしれませんが、通常は簡単に修正できる小さな構文エラーです。次に、さらにコードを作成するときにそれらを取得し始めたら、出てくるものを修正するだけです。

また、プロジェクトを常に最高レベルの警告である警告レベル 4 に保ちます。これにより、コンパイル時に、既定のコンパイラ (ビジュアルスタジオ) が間違っていると判断したものをすべて修正できます。

score 1 · Accepted Answer

また、それらをすべて一緒に修正する必要があると思います。その後、すべての警告をエラーとして扱うようにコンパイラの設定を切り替えることをお勧めします。

score 0 · Accepted Answer

あなたのプロジェクトが車だと想像してみてください。

車を始動するときに 30 ～ 40 の警告灯が点滅していたらどうしますか?

ビルドスクリプトが警告を出している場合は、少なくとも何が起こっているのかを確認する必要があります。なぜこの警告が表示されるのか。もちろん、警告付きで実行中のシステムの例を持つことはできますが、これはあなたが望むものではありません (私は期待しています)。

私たちはいくつかの静的コードアナライザーを使用しています。lime PMD または findBugs (両方とも Java 用)。各ビルドの後、これらのツールによって配信される警告も修正します。

なんらかの理由で警告が重要でない場合は、言語が @suppressWarning のようなものを提供しているかどうかを確認してください。実際、これは推奨事項ではありません。コメントのみです。

score 0 · Accepted Answer

意図的にコードを書いてください、草むしりさん。蝶の羽のようにもろく、蚕の繭のようにまとわりついている - 印刷された警告と同等の長さをコード化でき、エラーの痕跡を残さないとき、あなたは学んだことになる. ――マスター・ポー

受け取った警告が考慮に入れていなかったことにフラグを立てている場合は、引き続き警告をエラーとして扱い、すぐに修正する必要があります。

受け取る警告が常に意図的に行ったことに関するものであり、生成されたコードが意図したとおりに機能し、それらを修正するのにかかる時間が無視できない場合は、それらを無視できますが、新しい儀式が必要になります.エラーを修正するため。

現在無視されている警告が実際にエラーにフラグを立てているかどうかを確認するために、修正を行う際に各エラーを調べる必要があります。実行中のカウントを維持します。無視された警告が役に立たない限り、続行します。意味のある 2 つの警告を無視したことに気付いた場合は、すべての警告をエラーとして扱うように切り替えてください。時間をかけて改善してから、もう一度試してください。

score -1 · Accepted Answer

プログラマーの喫煙

通りの角に立ってタバコを吸っている男。通りすがりの女性が彼に気づき、言う。

「ねえ、それらがあなたを殺すことができることを知らないの？つまり、箱に巨大な警告が表示されていませんでしたか?!」</p>

「大丈夫です」と男は言い、さりげなく息を吐きます「私はコンピュータープログラマーです」</p>

"そう？それは何と関係があるのですか?」</p>

「私たちは警告を気にしません。私たちはエラーだけを気にします。」</p>

;)

私の提案は、ソリューションが完全に機能するまで無視することです。次に、警告の修正に進みます。業界はほとんどの場合「締め切り志向」であるため.;)

score -2 · Accepted Answer

私が実際に行っていること: 現在のプロジェクトでも 30 ～ 40 個の警告が生成されますが、無視しています。

私がすべきこと: それらのいくつかは意味があるかもしれないので、それらを修正してください。

c# - 警告を処理するためのベスト プラクティス

13 に答える 13

Related

Reference

c# - 警告を処理するためのベストプラクティス