AndroidとCheckstyle
Tweet
○Android Advent Calendar 2011
本エントリは、「AndroiderでAdvent Calendarやろうぜ！」という、Android Advent Calendar 2011企画中の1エントリになっております。
初日から割としょっぱい感じのエントリになってしまってすいません。きっと本日以降、他の方々は僕と違って素敵なエントリが並ぶと思いますのでぜひお楽しみに！
○Checkstyleって？
Java向けの「静的解析ツール」というやつで、設定したコーディング規約に沿わない箇所を検出したり、さらにはロジック上の矛盾を検出してくれたりするツールです。
そんなCheckstyleの設定XMLを、AOSPのformatterとセットの前提でAndroid向けにチューンした形でうまく作れないかな...と思ったのですが、結論としてはイマイチな感じになってしまいました。
○結論：環境にあわせて要カスタマイズ
とりあえず成果を以下に。
zip内にformatterとcheckstyleのxmlが含まれていますので、readmeを参照しながらEclipseで適用してみてください。
formatter_checkstyle.zip
参考にしたサイト：
Checkstyleのカスタムルール作成と共有：souta-bot log
http://d.hatena.ne.jp/souta-bot/20090617/1245256801
Android CheckStyle設定：memorandum
http://ksoichiro.blogspot.com/2011/05/android-checkstyle.html
○考察
・コンセプトは「守らざるを得ないぐらいゆるゆるルール」だったのですが、Javadocすごい大事ケースとそうでもないケースを1個のCheckstyle設定でまかなうのが厳しいです。
・「シングルトンインスタンス」とか「自明でコメント不要なJavadocパラメータ」等、違反とはしたくないイレギュラーパターンがそこそこ多く、修正を必須にするにはちょっと苦しい結果に。
・1回設定すれば自動で修正まで適用されるformatterと比較して、違反コメントから具体的にどう直すべきかが分かりにくいCheckstyleは適用コストが...。
・少々厳しい、付属のルールを1回かけて、必要なところのみ対応したり、ファイルヘッダ・クラスヘッダ・パッケージヘッダ等、忘れやすいところを中心にサポートする等の、適切な使い方を選択することがキモだと思われます。
以下、上記アーカイブのreadmeより、作成手順を抜粋。
○android-checkstyle.xmlの作成手順
以下のページを参考に、Javaのフォーマッター設定とCheckStyle設定のインポート用XMLを作成。
Checkstyleのカスタムルール作成と共有：souta-bot log
http://d.hatena.ne.jp/souta-bot/20090617/1245256801
＜以下参考元ページより＞
・雛形は既存（プラグイン付属？）の「Sun Checks (Eclipse)」のコピーを使用。
・Javadoc Comments - Method Javadoc - scope をpackageに
・Javadoc Comments - Method Javadoc - allowUndeclaredRTE をチェック
・Javadoc Comments - Style Javadoc - checkFirstSentence チェック外す
・Javadoc Comments - Variable Javadoc scope をpublicに
・Size Violations - Maximum Parameters チェック外す
・Coding Problems - Convariant Equals を追加
・Coding Problems - Default Comes Last はチェックONそのまま。
・Coding Problems - Fall Through を追加
・Coding Problems - Hidden Field - Parameter declaration チェック外す
・Coding Problems - Magic Number チェック外す
・Coding Problems - Parameter Assignment を追加
・Coding Problems - String Literal Equality を追加
・Class Design - Design For Extension チェック外す
・Miscellaneous - Final Parameters チェック外す
＜以下、独自変更＞
・Size Violations - Maximum Line Length チェック外す
@see等、1行の長いコメントを許容。Javaコード部の行長はformatterに任せる。
・Size Violations - Maximum Method Length - maxを150から300に
巨大なswitchやif-elseを許容。
・Naming Conventions - Member Name -^m[a-zA-Z0-9]*$ に変更、applyToPublicをチェック外す。
publicでないメンバ変数は小文字mから始まる様にする。
設定 - Java - コード・スタイルの変数命名規則の「field」の接頭辞に"m"を設定するのと合わせて。
・Whitespace - * 全部チェック外す
formatterに任せる。
・Modifiers（修飾子） - Redundant Modifier チェック外す
interfaceのmethodに主張としてpublicとか別につけてもいいと思う。（static final METHODはかっこ悪い気がしますが。）
・Block Checks - Empty Block optionをstmtからtextへ
空ブロックはコメントが入っていればokとする。
・Coding Problems - Avoid Inline Conditionals チェック外す
「条件(3項)演算子許可」※AOSPでは使われているから。新規では避けるべき。
・Coding Problems - Modified Control Variable は追加しない
「ループ変数のループブロック内での操作」を許容。
・Coding Problems - SuperClone を追加
・Class Design - Hide Utility Class Constructor チェック外す
呼べても意味がないがソースに無駄なコンストラクタが入るのでお好きにどうぞで。
・Class Design - Final Class チェック外す
継承されたくないクラスでのみ明示的につければ良い。
＜以下、気になるけどやり方不明＞
・@throws IOException I/O exceptionとか@param maxCount max countみたいな自明なコメント部を書かないでもいいようにしたい
・シングルトンのローカルインスタンスをprivate static final Hoge mHoge = new Hoge();みたいにすると、定数の命名規則にしろって怒られる。
コメントする