Android のコーディングガイドラインを俺訳

本格的に自分用。「訳」と書くのは釣り気味。

• 例外
  • 例外は無視するな。というか無視したくなるようなら設計が間違ってる。
  • Exception でなんでもかんでもまとめてキャッチするな。
• Finalizer 使うな。
• 完全修飾で import しろ。パッケージまとめてするな。
• スタンダードな Javadoc 書こう。
  • つまらないメソッドには書かなくていい。アクセッサとかいらない。
• メソッドは短く書け。
• フィールドの定義は、使う場所のすぐ上か、ファイルの先頭のどちらかでやれ。
• スコープはできるだけ限定するんだ。
• import 文の順序は「android」「サードパーティライブラリ」「java/javax」がいい。
• インデントにはスペースを使う。1インデントは4スペース。行の折り返しは8スペース。
• フィールド名は以下のルールでやる。
  • 非パブリックなインスタンスフィールドは頭文字を m とする。
  • スタティックフィールドは頭文字を s とする。
  • その他のフィールドは小文字ではじめる。
  • public static final なフィールドは全部大文字、_ 区切りで。
• 始まりの中括弧は同一行に書く。終わりの中括弧は独立行とする。
  • if 文の本体が1行しかない場合、まとめて書いてもいい。if(true) hogehoge();
• 一行はだいたい100文字くらいでお願いします。
• 普通の Java アノテーション使おう。Deprecated、Override、SuppressWarnings。
• 頭文字で構成された単語は、普通の単語として変数名ルールに従う。
• TODO: コメントはよいプラクティスなので使うべき。だけど完璧ではない。
  • もし、「将来あれこれする」式のコメントを書くときは、明確な日付かイベント名を書き加えるといい。
• ログはパフォーマンスに多大な影響を与える。気をつけろ。
• 肝心なのは一貫性。グローバルスタイルは大事だけど、ローカルスタイルはもっと大事。統一感がないコードは読む人をびっくりさせちゃうぜ。
• テストメソッド名は、_ で区切ってもいいよ。

インスタンスフィールドの接頭文字 m ってなんだろう。=> member variable っぽい。

調べたら、詳細な訳もあった。 http://www.textdrop.net/android/code-style-ja.html