41-無駄な警告を排除する

「プログラマが知るべき97のこと」の41個目のエピソードは、コンパイラによる警告に関する話です。静的な型付けの強い言語を好むプログラマならば、強く意識しておきたいエピソードです。静的な型付が強いコンパイル言語の場合、ソースコード上の誤りの多くはコンパイル時に解決されます。つまり、ソースコード上に致命的な問題があればエラーが、致命的ではないが何らかの問題を含む可能性がある場合は警告が報告されます。コンパイルエラーの場合はプログラムを動かす事ができませんので、誰もが修正をするでしょう*1。しかし、警告は忙しさなどを言い訳にして放置してしまうことがあります。このエピソードでは、それらの警告を放置することがどんな問題を引き起こすのかについて書かれています。
警告は発生したならばその場で解決するべきです。１つ２つの警告であれば何時でも修正する事ができるかもしれませんが、それらを放置して累積していくと、大きな技術的負債へとなっていくのです。また、新たに発生した比較的に致命的な警告を見過ごしてしまう可能性もあります。１つの警告を排除することは大きな手間ではないので、常に警告を排除し、コードをクリーンに保つことが重要です。
テストやドキュメントに関することも同様のことが言えるでしょう。「まとめてやる」は「たぶんやらない」と同等です。すべての事をその時にやることは不可能かもしれませんが、可能な限りその場でやるように心がけます。ユニットテストであればテスト駆動開発を意識した上でカバレッジを測定し、あるライン（例えば80％）以下にならないようにするなどのルールを作ると良いと思います。
また、Javaなどの言語では静的解析ツールが豊富に用意されています。FindBugs, CheckStyle, Code Coverage, Metricsなどコンパイル時などに様々な視点でソースコードをチェックすることが可能です。Eclipseのプラグインとして設定しておけば、開発中に常にチェックする事ができます。そして、警告を無視しないように開発を進める事をチームのルールとすることでソースコードの素性はずっと良くなるでしょう。経験の浅いプログラマにとっては大きなコストとなるかもしれませんが、警告が発生したならばその原因を考えて熟練者に相談して解決する習慣が出来れば、長期的にみてプラスとなるでしょう。ただし、FindBugs等のツールの導入は可能な限り早い段階で、なるべくならば開発初期から取り込むべきです。途中から導入してしまうといきなり発生した大量の警告に戦う気力がなくし、警告を無視せざるを得なくなります。
静的型付けの強い言語では、コンパイラや静的解析ツールによるチェックは強力な武器です。熟練したプログラマであれば、警告を出すようなコードはほとんど書かないでしょう。後から静的解析ツールを使っても修正可能な量なはずです。しかし、導入することにより大きな安心感を得ることが出来ます。個人的にはコンパイラや静的解析ツールによるチェックはユニットテストとして捉えています。警告を無視しているということは、ユニットテストであればレッドのテストをIgnoreにしているようなものです。

プログラマが知るべき97のこと

*1:ごく希にコンパイルエラーとなるコードをCSMにコミットする方もいますが…