GoogleのJavaコーディング規約である Google Java Style の、ポイントとなりそうなところを独断と偏見で並べてみました。
インデントはスペース2 (4.2節)
今風っぽい感じですが、これまでは4がデファクトであることと、現存ソースへの影響が大きすぎる（全行対象！）ので、既存システムのメンテナンスでは適用できないかもですね。ただ、これだとソースがコンパクトになった気がして良いと思います。個人的にこれから書くソースは2にすることにしています。Qiita上でソースを書くこともありますが、スマホで読む人も居るだろうと考えた次第です。
import文とpackage文は改行しない (3.2節 3.3.2項)
「そんなのEclipseでフォーマット設定できるのか？」と思って調べてみたところ、Eclipse(Mars.2)上で設定する項目は見当たりませんでした。試しに階層が深いパッケージを作ってフォーマット(Ctrl + Shift + f)を試してみたところ改行されませんでした。IntelliJ IDEA 15.0.4(Community Edition)でも同様でした。そもそもそういう仕様だということですね。
1行は100文字まで (4.4節)
以前は80あるいは100という規約だったのですが、100に変更（緩和？）されたようです。依然厳しいような気がします。ただ例外もあって、コメント中に長いコンソール上のコマンド例を入れる場合や、長いURLがあって不可能な場合や、package文や、import文は例外としています。（自動ツールでこう言うの表現できるのかな、、、？）
守れたら読みやすくなるでしょう。どこかで基準を設けないと限りなく伸びるものなのでそういう意味では制限を入れるのは正しいと思います。インデントは2、このルールはpackage文import文には適用されないので頑張って心がければ100なら行けるかもしれません。
水平位置揃えは不要 (4.6.3項)
水平位置揃えというのはこういうものです。
String nantoka;
int kantoka;
フィールド名のカラム位置が揃っています。これは推奨ではなくて、
String nantoka;
int kantoka;
のように、カラム位置はそれぞれ行毎に決定することを推奨するとのことです。
確かに、最初に開発するときはカラムが揃っていて見やすいのですが、フィールドを追加削除していると修正範囲が広がってしまって継続的にメンテする人が不幸になるパターンだと思います。旧来のアタマだとやってしまいがちなので、規約で扱いを明らかにするのは有意義かと。
フィールドだけでなく、長いSQLの組み立てなどで項目を1行ずつ書きたい場合もあると思います。こういう時に、行末に末尾を書いてその水平位置を揃えたくなる向きもあると思いますが、そういうのも避けたほうが良いですね。
例えば、
StringBuilder sql = new StringBuilder();
sql.append("select ");
sql.append("id "); // ID番号
sql.append("name "); // 名前
sql.append("address "); // 住所
sql.append("email "); // Email
こういうのはやめて、
StringBuilder sql = new StringBuilder();
sql.append("select ");
// ID番号
sql.append("id ");
// 名前
sql.append("name ");
// 住所
sql.append("address ");
// Email
sql.append("email ");
こうしたほうが良いと思います。コメントの水平位置を揃えようとしたら負けです。
命名関係
命名に、接尾辞・接頭辞は 使わない。 (5.1節)
命名において、 name_ 、 mName 、 s_name や kName といったような命名はしないとのこと。いわゆるハンガリアンはやらないということですね。古臭さが除去出来て良いのかもしれません。
ロガーは コンスタントケース(CONSTANT_CASE)ではない。(5.2.4節)
ロガーというのはいわゆるこういうものです。
static final Logger logger = Logger.getLogger(MyClass.getName());
定数ではないので小文字キャメルケース(lowerCamelCase)で命名せよとのことです。私としてはstatic final なものは一律コンスタントケースで良いと思います。そのほうが自動化チェックし易いですし。
「iOS」をキャメルケースにすると 「Ios」 (5.3節)
違和感ありますが、そこまででもきっちり管理したいということなのでしょう。
触れられていないこと
- クラス名行数制限、メソッド名行数制限 (一律的な基準を作るのは難しいのかも)
- メトリクス関係（一律的な以下略）