読者です 読者をやめる 読者になる 読者になる

kazurof weblog

技術ネタのメモを並べます

GoogleのJavaコーディング規約について

やや旧聞な感じですが、GoogleJavaコーディング規約(Google Java Style)について読んだ感触を並べてみます。

ドキュメンテーションコメント」という言葉は使わない。

Sunの文書では、

  1. APIリファレンスを作成するjavadocツール、 
  2. javadocツールに処理されるドキュメンテーションコメント。 (/* ... / こういうの) 
  3. 生成されたAPIリファレンス、 

をそれぞれ分けていて、2にドキュメンテーションコメントという名前をつけていました。googleの規約では単に2番を javadoc と呼ぶようです。慣習上の名前をそのまま規約化したということですね。

インデントはスペース2個。けど4個の場合もある。

あー、なにげに画期的かも。小さいことはいいことだ。

1行は80文字か100文字

これ大丈夫でしょうか。インデント2個ならいけるのかな?元々の80の根拠はかなり古い歴史的理由なわけで、ここはひとつ120文字ぐらい許可してもいいのではとも思います。守れるかな?import packageには及ばないのはそこそこの落とし所かも。

クラスメンバーの順序は特にルールはない。けどオーバーロードしているものは連続させる。

staticなものが先とか、コンストラクタはメソッドの先とか考えることはできて、ルール無しは緩すぎ?とも思うけどまあそんなものかも。

Loggerは定数ではない。static finalにはしない。

いやー、そうかなー。機械的にチェックさせるには、static final なものは全部定数扱いにしたほうが良いと思うけど。ルールは単純で機械でもついてこれるものがいいよ。Checkstyleとか。

@return よりも、本文を書く。

これはいい。さすがGooglejavadocタグよりも要約のところになにか出てくるほうが目立つしね。


以上、それなりによくまとまっているなという印象でした。1行100文字ルールはどこまで行けるかなー?下手をすると、クラス名がバッティングして完全修飾クラス名をコード中に書かざるを得なくなったら守れなくなりそうだけど。

あと、英語の原文を無理やり翻訳してみました。間違いもあろうと思います。参考までにどうぞ。

GoogleJavaStyle-ja/GoogleJavaStyle-ja.textile at master · kazurof/GoogleJavaStyle-ja · GitHub

いずれ、Checkstyleの定義ファイルとか、Eclipseのコードテンプレート設定ファイルとかもつくって上げたいと思います。時間が取れれば。。。