きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

コンパイル警告が嫌い

神経質なのかも知れないが、コンパイル警告が嫌い。


だから、出来るだけ警告されないように書くし、
警告されても揉み消してもいいならもみ消す。


@SuppressWarnings("unused")
未使用変数だったら出る警告。
→正直、要らないコードのケースが多い。「作りかけかよ?」と思うこと多々。
→テストケースで多く出るので、僕はごりごりunusedを付けていく。


@SuppressWarnings("unchecked")
総称型をraw型で使ってると出る警告。
→コード補完でやると、メソッドにuncheckedを付けに行くが、これは良くない。ちゃんとローカル変数に付けよう。


未検査のキャストなんかで出る警告。
Map map = new HashMap();
Map ret = (Map) map;
→総称型を使ってるとけっこう出てくるんだけど、作りが悪いと回避出来ないことが多い。


@SuppressWarnings("serial")
SeriazableをimplementsしてるのにserialversionUIDを書いてないと出る。
→つーか、コード補完で、自動生成しろって。


@SuppressWarnings("finally")
finallyが終わらないようなコードに見えたら出る??
ほぼほぼバグってるだろうから、付けるのはどうかと思う。


@SuppressWarnings("deprecation")
非推奨メソッドを使ってると出る。
いやー、揉み消すのは止めとこうよ。


@SuppressWarnings("fallthrough")
switchで、breakさせずに、次のcaseに突入させると出る。
これはメソッド全体に付けないと消せないのかな??
まあ、ちゃんとbreakした方がバグ出にくいからな。




僕が警告が嫌いなのは大した理由は無い。
ただ単純に色に反応してるだけだ。


嫌いな理由にもっともらしい理由を考えてみた。
警告が森になったら、大事な木を見つけにくいってことだ。


あと、@Overrideアノテーションで前から気になっていたことがある。
前は、implementsするメソッドに@Overrideは付けられなかった。
どうやらJavaSE6から付けられるようになったらしい。
この人の日記がよくまとまってると思う。
http://d.hatena.ne.jp/waman/20090421/1240325650


いまやってる仕事だと、JavaSE5にしか対応してない環境がある。
JavaSE6をベースに作っていて、その資材をJavaSE5でしか動かない環境に持っていく際、
コンパイラ準拠レベルを1.5にして持っていくことになるかも知れないのだが、
@Overrideアノテーションの使用方法の変更というものが起因して、
コンパイルエラーになることに今気付いた。あー、うざいな。
そういえば、@PostConstructとかJavaSE6からなんで、オレの作ったコンテナ自体が動かないです。
あはは、致命的じゃん。



@SuppressWarningsの情報を追加
@SuppressWarnings("nls")
文字リテラルをベタ書きしてるのと出るコンパイル警告を打ち消す。
これをやっておくと、後で国際化するのが楽になると思うよ。
@SuppressWarnings("static-access")
staticにアクセスすればいいのにインスタンスの変数からアクセスする場合に出るコンパイル警告を打ち消す。
@SuppressWarnings("unqualified-field-access")
インスタンス変数なんかにアクセスする際、thisを付けずに書くと出るコンパイル警告を打ち消す。
@SuppressWarnings("boxing")
オートボクシングに任せてしまってると出るコンパイル警告を打ち消す。
@SuppressWarnings("hiding")
よくあるのはJavaBeanのインスタンス変数と、セッターメソッドのパラメータ変数が同一の時に出るコンパイル警告。
他にあるのはスーパークラスのインスタンス変数(protected)とサブクラスのローカル変数が同じ場合に出るコンパイル警告。
@SuppressWarnings("null")
nullで到達してしまうことがあるのが明らかな時に出るコンパイル警告を打ち消す。
こんなの付けずにちゃんとコードを書こう。