ルールが存在するからこそ、自由や安心を得られる。
プロジェクト開発においても同様に様々なルールがあり、
それを遵守するからこそ品質を保障できると考えられている。
その中でプログラマには、コーディング規約の遵守が義務付けられるのだが、
規約内容が希薄であったり、曖昧な表現で記載されていることも少なくない。
また、開発の途中でルールが制定されるなんてことも頻繁にある。
プログラマにとっては、その対応だけで無駄な労力を使うことになってしまう。
そんな時に役立つのが、｢CheckStyle｣である。
このプラグインにコーディング規約を設定することで、
プロジェクト全体で統一感のある開発をスムーズに行うことが可能となる。
今回は、SunのCheckStyleを利用して、
CheckStyle対応前と対応後のプログラムを比較してみよう。
＜修正前＞
1行目:最終行が改行されていない。
3行目:・Javadocコメントがない。
・ファイナライズされていない。
・publicなコンストラクタが存在する。
(public staticなメソッドしかないのでUtilityクラスと判断された為)
4～20行目:インデントがタブとなっている。
4行目:・Javadocコメントがない。
・パラメータがファイナライズされていない。
・[]の位置が不正。
5,7行目:プログラム中にベタで値が登場している。
(ファイナライズした変数(or定数)を使用しなくてはいけない)
但し、1や2はベタでもOKの模様。
＜修正後＞
