GoogleのJavaコーディング規約について
やや旧聞な感じですが、GoogleのJavaコーディング規約(Google Java Style)について読んだ感触を並べてみます。
「ドキュメンテーションコメント」という言葉は使わない。
Sunの文書では、
- APIリファレンスを作成するjavadocツール、
- javadocツールに処理されるドキュメンテーションコメント。 （/* ... / こういうの）
- 生成されたAPIリファレンス、
をそれぞれ分けていて、２にドキュメンテーションコメントという名前をつけていました。googleの規約では単に２番を javadoc と呼ぶようです。慣習上の名前をそのまま規約化したということですね。
インデントはスペース２個。けど４個の場合もある。
あー、なにげに画期的かも。小さいことはいいことだ。
１行は８０文字か１００文字
これ大丈夫でしょうか。インデント２個ならいけるのかな？元々の８０の根拠はかなり古い歴史的理由なわけで、ここはひとつ１２０文字ぐらい許可してもいいのではとも思います。守れるかな？import packageには及ばないのはそこそこの落とし所かも。
クラスメンバーの順序は特にルールはない。けどオーバーロードしているものは連続させる。
staticなものが先とか、コンストラクタはメソッドの先とか考えることはできて、ルール無しは緩すぎ？とも思うけどまあそんなものかも。
Loggerは定数ではない。static finalにはしない。
いやー、そうかなー。機械的にチェックさせるには、static final なものは全部定数扱いにしたほうが良いと思うけど。ルールは単純で機械でもついてこれるものがいいよ。Checkstyleとか。
@return よりも、本文を書く。
これはいい。さすがGoogle。javadocタグよりも要約のところになにか出てくるほうが目立つしね。
以上、それなりによくまとまっているなという印象でした。１行１００文字ルールはどこまで行けるかなー？下手をすると、クラス名がバッティングして完全修飾クラス名をコード中に書かざるを得なくなったら守れなくなりそうだけど。
あと、英語の原文を無理やり翻訳してみました。間違いもあろうと思います。参考までにどうぞ。
GoogleJavaStyle-ja/GoogleJavaStyle-ja.textile at master · kazurof/GoogleJavaStyle-ja · GitHub
いずれ、Checkstyleの定義ファイルとか、Eclipseのコードテンプレート設定ファイルとかもつくって上げたいと思います。時間が取れれば。。。
