web-dev-qa-db-ja.com

コードで抑制警告を使用することは良い習慣ですか？

私は@SuppressWarnings("unchecked")と@SuppressWarnings("null")のほとんどのメソッドを使用して、警告なしにコードをコンパイルできるようにしていますが、疑問があります。このStackoverflowが見つかりました question 。 Jon Skeetが answer を書きましたが、これは興味深いものです。

彼によると、

時々Javaジェネリックはあなたがやりたいことをさせないだけで、あなたがしていることは実行時に本当に合法であることをコンパイラに効果的に伝える必要があります。

しかし、例外がスローされる可能性がある場合はどうなりますか？警告を抑制するのは悪い考えではありませんか？問題が表面化する可能性のある場所を意識する必要はありませんか？

また、後で誰かが私のコードを変更し、SuppressWarningsを削除せずに疑わしい機能を追加した場合はどうなりますか？どうすればそれを回避できますか、これに代わる方法はありますか？

@SuppressWarnings("unchecked")と@SuppressWarnings("null")を使用する必要がありますか？

更新＃1

未チェックの型キャストが実行される限り、これ answer （以下のコメントで@gnatによって指摘）に従って、これらの警告を抑制することが必要です。

多くの不可欠なJavaライブラリは、安全でない型キャストの必要性を排除するために更新されたことはありません。これらの警告を抑制することは、他のより重要な警告に気づき修正するために必要です。

他の警告を抑制する場合は、まだ少し灰色の領域にあります。

更新＃2

Oracle Docs のとおり（以下の回答でも言及）：

スタイルの問題として、プログラマは常にこのアノテーションを効果的な場所で最も深くネストされた要素で使用する必要があります。特定のメソッドで警告を抑制したい場合は、クラスではなくそのメソッドに注釈を付ける必要があります。

javaexceptionsruntimetype-castingwarnings
11
Bilesh Ganguly

私にとって、警告を抑制する目的は、プロジェクトの「健全な法案」を維持することです。コードベース全体が正常にコンパイルされていることがわかっている場合、誰かが何か問題を起こしたときに、最初の警告が指摘リストに表示されるのはすぐにわかります。次に、エラーを修正するか、それが偽であることが証明できる場合はそれを抑制できます。

しかし、最初に21個の警告がある場合、誰かがそれを引き起こしたときに22番目の警告を見落とす可能性がはるかに高く、あなたはしないでください無害であることを確認します。つまり、問題がコードベースに侵入し、気付くことはありません。

警告は有用な情報項目です。真実を話す人に注意し、そうでない人を除外してください。あなたがあなたの早期警告システムを失うように、人々が2種類を混同させないでください。

編集

メリットのある警告を抑制することは愚かなことであることをおそらく明確にすべきです。あなたが不正行為によって得たきれいな健康法案は明らかに何の価値もありません。選択した場合、目を閉じるだけでなく、コンパイラが気づいた問題を常に修正する必要があります。ただし、問題があるかどうかをコンパイラーが判断できない領域があり（Javaのジェネリックはそのような領域の1つです）、そのような各インスタンスを確認してから、この特定の場所で警告を抑制する方が適切です。このクラスの警告を完全にオフにして、本物の警告を見逃す可能性よりも。

26
Kilian Foth

警告の抑制は、細心の注意を払って行う必要があるものです。

警告の意味：コンパイラは、怪しげに見える何かを見つけました。それはそれを意味するわけではありませんis怪しげです、それはコンパイラにとってそれのように見えます。完全に問題がなく、警告を出すコードがある場合があります。場合によっては、コードを少し変更して修正します。コンパイラには、その目的のために特別な機能がある場合があります。例えばどこ

if (x = someFunction ()) { ... }

警告を出しますが

if ((x = someFunction ())) { ... }

しません。最初のケースでは、=ではなく==を意味していると想定した警告。 2番目のケースでは、余分な括弧がコンパイラに「私は何をしているのかわかっている」と伝えるため、警告はありません。もちろん良いでしょう

if ((x = someFunction ()) != 0) { ... }

または2行を使用します。

そして、ごくまれに、コードに問題がない場合でも、警告なしに受け入れられる方法でコードを記述できない場合があります。その非常にまれなケースでは、そのステートメントの警告を無効にして、直後にオンにします。それが最後の手段です。そして、あなたはその特定の警告だけを無効にし、他のものは無効にしません。

ただし、一部の人々は、警告を無効にするために警告を無効にするだけです。なぜなら、彼らは、正当な警告の理由を最初に見つけて修正するのが面倒だからです。または、警告のないコードを記述しようとはしません。それは非常に不健全なことです。

16
gnasher729

メソッド全体の警告を抑制することは疑わしいです。特定の行（コメント付き）の警告を抑制する方が良い。例えば.

@SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast

7
user949300