IDE の設定とうまく合うよう、次のようにインポートすべきです。

なぜ？

もともとは、インポートの順序についてのスタイルはありませんでした。これは、常に IDE が順序を変えるのに任せるか、さもなくば、IDE にある自動のインポート管理機能を無効にして手動でインポートを管理しなければならない、ということを意味します。これはひどい話のように思えました。java-style が尋ねられると、望ましいスタイルはすべてここにあることでした。結局「順序をひとつ選んで一貫性をもたせる」ことが必要になりました。そこで、私たちはスタイルをひとつ選んで、javaguideをアップデートし、IDEがそれに従うようにしました。私たちが期待しているのは、IDEのユーザがコードを書いているうちに、余計なエンジニアリング作業をせずとも、すべてのパッケージがこのパターンに沿ってインポートされることです。

私たちの選んだスタイルは次のようなものです。

スタティックインポートをどうするか？

ほとんどの人がこれを優先度の低い問題だと考えているので、各自の判断にまかせることにしました。ただし、一貫性をもたせるようにしてください。

インデント

ブロックのインデントにはスペース4つを使ってください。タブを使ってはいけません。迷ったときには、まわりにあるコードを見て一貫性をもたせてください。

関数呼び出しと引数を含んだ行の折り返しは、スペース8つでインデントしてください。例えば、これは正しいインデントです。

Instrument i
        = someLongExpression(that, wouldNotFit, on, one, line);

Instrument i
    = someLongExpression(that, wouldNotFit, on, one, line);

フィールド名

• 非パブリック、非スタティックフィールドの名前は m で始めてください。
• スタティックフィールドの名前は s で始めてください。
• それ以外のフィールドは小文字で始めてください。
• パブリックな static final フィールド（定数）はアンダースコアを含む大文字だけにしてください（例えば、ALL_CAPS_WITH_UNDERSCORES）。

例:

public class MyClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;
}

中括弧

中括弧で行を始めてはいけません。中括弧はその直前のコードと同じ行に置いてください。つまり、次のようになります。

class MyClass {
    int func() {
        if (something) {
            // ...
        } else if (somethingElse) {
            // ...
        } else {
            // ...
        }
    }
}

条件文には中括弧を付けてください。ただし、条件文全体（条件と本体）が1行に収まるのであれば、中括弧を付けなくても構いません（そうしなければならないわけではありません）。つまり、これも許されます。

if (condition) {
    body; // ok
}
if (condition) body; // ok

でも、これは許されません。

if (condition)
    body; // bad

行の長さ

コードにおけるテキスト行は、せいぜい100文字までにするべきです。

このルールについてはかなり議論があったのですが、結局は最長100文字のままとなりました。

例外: コメント行に100文字以上のコマンド例やURL文字列が含まれる場合には、100文字を超えても構いません。コピー＆ペーストしやすくするためです。

例外: インポートの行はこの制限を超えても構いません。ただし、めったにないでしょう。この方がツールを書くのも簡単になります。

Java 1.5 アノテーション

アノテーションは同じ言語要素にある他の修飾子よりも前に置くべきです。単純なマーカーアノテーション（例えば @Override）であれば、言語要素と同じ行に並べても置いても構いません。アノテーションが複数あったり、パラメータ付きのアノテーションの場合には、アルファベット順に1行ずつ並べるべきです。

Java 1.5 で定義された3つのアノテーションについて、以下が Android 標準のプラクティスです。

@Deprecated

その要素の利用がもはや推奨されないときには、@Deprecated アノテーションを必ず付けなければなりません。@Deprecated アノテーションを使うときには、@deprecated Javadoc タグも付けなければなりません。そして、その代わりに使う実装について説明しておくべきです。@Deprecated メソッドはまだ動作がサポートされていることも意味していることを忘れてはいけません。

もし @deprecated Javadoc タグが付いた古いコードがあれば、@Deprecated アノテーションを追加しておきましょう。

@Override

メソッドがスーパークラスにある宣言や実装をオーバーライドしているときには、@Override アノテーションを必ず付けなければなりません。

例えば、もし {@inheritdocs} Javadoc タグを使っていて、クラス（インタフェースではなく）から派生しているときには、メソッドが親クラスのメソッドをオーバーライドしていることを示すために @Override アノテーションを付けなければなりません。

@SuppressWarnings

@SuppressWarnings アノテーションは、どうしても警告を取り除けない事情がある場合にのみ使うべきです。警告を「取り除けない」と判断したときには、@SuppressWarnings アノテーションを付けなければなりません。すべての警告がコード上にある実際の問題を反映できるようにしておくためです。

@SuppressWarnings アノテーションが必要になったときには、その直前に TODO コメントを入れて、その警告を「取り除けない」事情について説明しておかなくてはいけません。こうすることで、やっかいなインタフェースをもつ問題のあるクラスだということがわかります。例:

// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
@SuppressWarnings({"generic-cast"})
List<String> blix = Utility.rotate(blax);

@SuppressWarnings アノテーションが必要になったときには、コードをリファクタリングして、アノテーションが適用されるソフトウェア要素を他から分離すべきです。

名前における頭字語（アクロニム）

頭字語や略語は単語として扱ってください。その方が読みやすい名前になるためです。

頭字語や略語そのものが名前の場合にも、このスタイルが適用されます。

頭字語について、JDK と Android のコードベースはいずれも、まったくと言っていいほど一貫性がありません。そのため、まわりのコードとの一貫性をもたせることは事実上不可能です。それでもグッとこらえて、どうか頭字語を単語として扱ってください。

このスタイルルールについて、もっと理由が必要であれば、 Effective Java Item 38 と Java Puzzlers Number 68 を読んでください。

TODO のスタイル

コード中の TODO コメントは、一時的なものや、短期的な解決策、その場しのぎで完全ではないところなどに使いましょう。

TODO にはすべて大文字の "TODO" にコロンを続けたものにすべきです。

  // TODO: Remove this code after the UrlTable2 has been checked in.

  // TODO: Change this to use a flag instead of a constant.

もし TODO が「将来の日付に何かする」という形式であれば、具体的な日付が入っているか（「2005年11月までに修正」など）、もしくは具体的なイベントが入っているか（「すべての製造ミキサーがプロトコルV7を理解できるようになればこのコードを削除する」など）を確認しましょう。

一貫性

最後に考えること: 一貫性をもたせましょう。コードを書いているなら、数分かけてまわりのコードを調べて、スタイルを決めましょう。もし if 節のまわりに空白があれば、あなたもそうすべきです。もしスターで囲まれた小さなボックス型のコメントが使われていれば、あなたのコメントもそうしましょう。

スタイルガイドラインがあるということは、コーディングに共通のボキャブラリがあるということです。これがあるおかげで、どうやって話すのかではなく、何を話すのかに全員が集中できるようになります。このガイドラインでは、全般的なスタイルに関するルールを説明しました。これでボキャブラリについてはわかったはずです。ただし、ローカルなスタイルも重要です。あなたの追加したコードが、まわりにある既存のコードと全然違って見えてしまうと、コードを読む人は不連続さを感じて、リズムが狂ってしまいます。これは避けましょう。

ログ記録

ログ記録は必要不可欠なものですが、適度に簡潔にしておかないとパフォーマンスにかなり悪影響を与えて、すぐに役立たずなものになります。ログ記録ファシリティには5つのレベルがあります。それぞれのレベルをいつどのように使うべきか、以下に説明します。

• ERROR: このレベルは何か致命的なことが発生したときに使うべきです。つまり、ユーザにとって目に見えて重大で、明確にデータの削除やアプリケーションのアンインストール、データパーティションの削除、電話全体の再起動（あるいは、もっともっと悪いこと）をしなければ復旧不能な問題が発生したときです。このレベルは必ずログに記録しておきましょう。 通常、ERROR レベルでログ記録するような問題は、統計収集サーバに報告するようにしておくのが望ましいです。
• WARNING: このレベルは深刻な予期せぬことが発生したときに使うべきです。つまり、ユーザにとって目に見えて重大ですが、特定のアクションを実行すればデータを失うことなく復旧可能な問題が発生したときです。このアクションには、しばらく待つだけやアプリを再起動することから、アプリケーションの新しいバージョンを再ダウンロードしたり、デバイスをリブートすることまで、さまざまです。このレベルは必ずログに記録しておきましょう。 WARNING レベルでログ記録するような問題も、統計収集サーバに報告するのを検討した方が望ましいです。
• INFORMATIVE: このレベルは多くの人にとって関心のあることが発生したことを通知するために使うべきです。つまり、広範囲に影響がありそうだが、必ずしもエラーではないような状況です。これは、そのドメインでいちばん信頼できると思われるモジュールだけが、ログを記録すべきです。（信頼できないコンポーネントによって、ログが二重に記録されるのを防ぐため）。このレベルは必ずログに記録しておきましょう。
• DEBUG: このレベルはデバイスに何が発生しているのか、想定外の動作を調査、デバッグするための情報を記録するときに使うべきだ。あなたのコンポーネントに何が起こっているのか、必要十分な情報だけをログに記録すべきです。 もしデバッグログがログの大部分を占めるようであれば、VERBOSE レベルで記録すべきでしょう。DEBUG レベルはリリースビルドでも記録されるため、if (LOCAL_LOG) ブロックや if (LOCAL_LOGD) ブロックで囲んでおく必要があります。この LOCAL_LOG[D] はクラスやサブコンポーネントで定義され、こうしたログをすべて無効にできるようになっています。 そのため、if (LOCAL_LOG) ブロックにはアクティブな論理を入れてはいけません。ログのための文字列構築も if (LOCAL_LOG) ブロックのなかに入れておく必要があります。もし if (LOCAL_LOG) ブロックの外側で文字列構築しようとしているなら、ログ記録の呼び出しをメソッド呼び出しにリファクタリングすべきではありません。まだ if (localLOGV) を使っているコードもあります。これもまだ使えますが、名前付けは Android の標準に従っていません。
• VERBOSE: 以上のどのレベルにも当てはまらないログはすべて、VERBOSE レベルを使うべきです。このレベルはデバッグビルドだけでログが記録されるよう、if (LOCAL_LOGV) ブロック（あるいは同等のもの）で囲んでおくべきです。こうすることで、デフォルトではコンパイルされなくなります。ログに関する文字列構築はリリースビルドに入らないよう、if (LOCAL_LOGV) ブロックのなかに入れておく必要があります。

注意: VERBOSE レベルを除いて、可能な限り、エラー報告はモジュール内で一度だけにすべきです。モジュール内の一連の関数呼び出しでは、いちばん内側にある関数だけがエラーを返すべきです。そして、同一モジュールにある呼び出し元がログを追記するのは、問題を切り分けるのに非常に有益なときにだけにすべきです。

注意: 複数のモジュールが連携している場合には、上位レベルのモジュールからやってきた不正なデータを、下位レベルのモジュールで検出することがあります。このときには、VERBOSE レベルを除いて、下位レベルのモジュールでのみ、その状況を DEBUG ログに記録すべきです。しかも、ログ記録するのは、呼び出し元からはわからない情報がある場合にのみにしましょう。具体的に言うと、例外が投げられたり（例外には関連する情報がすべて含まれているはずです）、ログ記録する唯一の情報がエラーコードに含まれている場合には、ログに記録する必要はありません。このことは、フレームワークとアプリケーション間のやりとりでは特に重要になります。サードパーティ製アプリケーションに原因があり、フレームワークがそれをうまく処理する場合には、DEBUG レベルよりも高いレベルでログ記録すべきではありません。モジュールやアプリケーションでは、同レベルあるいは下位レベルからやってきたエラーを検出したときにのみ、INFORMATIVE レベル以上でログ記録しましょう。

注意: 通常でも、ログを記録する必要のある状況が何度も発生する可能性があるときには、同じ（あるいはよく似た）情報でログがあふれないよう、ログ記録を制限する仕組みを実装するとよいでしょう。

注意: ネットワークの切断はよくあることなので、あらかじめ十分想定しておきましょう。特別な理由がない限り、これをログに記録すべきではありません。アプリケーションに重大な影響を及ぼすようなネットワークの切断は、DEBUG レベルか VERBOSE レベルでログ記録しておくべきです（リリースビルドでもログ記録しておくほど結果が深刻であり想定外であるかによります）。

注意: ファイルシステムへのアクセスあるいはサードパーティ製アプリケーションの動作によって、ファイルシステムがいっぱいになったとき、この状況を INFORMATIVE レベル以上でログ記録すべきではありません。

注意: 信頼できないソース（共有ストレージにあるファイルやネットワーク経由のデータも含みます）から不正なデータがやって来ることは十分想定されることであり、たとえ不正なデータを検出しても、DEBUG レベルよりも高いレベルでログ記録すべきではありません。（できるだけログを記録するするのを限定すべきです）。

注意: String オブジェクトに対して '+' 演算子を使うと、知らないうちにデフォルトのバッファサイズ（16文字）をもつ StringBuilder オブジェクトと、ごくわずかな一時的な String オブジェクトが生成されていることを覚えておきましょう。 つまり、デフォルトの '+' 演算子に任せるよりも、明示的に StringBuffer オブジェクトを生成した方がコストがかからない（しかも、実際にはずっと効率がよくなる）ということです。また、Log.v() の呼び出しは、リリースビルドでもコンパイルされて実行されることを覚えておきましょう。たとえログが読めなくても、文字列構築は実行されています。

注意: 他人に読んでもらうようなリリースビルドでも有効なログは、曖昧さのない簡潔なものにすべきです。そして、非常に理解しやすいものにすべきです。これには DEBUG レベルまでの、すべてのログ記録が含まれます。

注意: ログ記録は意味が通じる限り、1行に収めるべきです。1行が80文字から100文字であれば、まったく問題ありません。（タグの長さも入れて）130文字あるいは160文字を超えるのは、できる限り避けるべきです。

注意: 成功したことをログに記録するときには、VERBOSE レベルより高いレベルにしてはいけません。

注意: 再現困難な問題を調査するために一時的にログを記録するときには、DEBUG もしくは VERBOSE レベルにするべきです。そして、if ブロックで囲んで、コンパイル時にすべて無効にできるようにしておくべきです。

注意: ログ全体を通して、情報漏洩には注意しましょう。プライベートな情報をログに記録するのは避けるべきです。保護されている内容に関する情報は、絶対に記録してはいけません。フレームワークのコードを書いているときには、これは特に重要になります。ある情報がプライベートもしくは保護されている内容であるか否か、事前に知るのは簡単ではないためです。

注意: System.out.println()（またはネイティブコードの printf()）を使ってはいけません。System.out と System.err は /dev/null にリダイレクトされます。したがって、いくら print 文を書いても見えません。にもかかわらず、呼び出しに伴って発生する文字列構築はすべて実行されてしまいます。

注意: ログ記録には鉄則があります。あなたのログが不必要に他人のログを押し出さないようにしてください。他人のログがあなたのログを押し出さないようにするのと同じようにね。

Javatestのスタイルに関するルール

テストメソッドの名前付け

例:

    testMethod_specificCase1 
    testMethod_specificCase2

void testIsDistinguishable_protanopia() {
    ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
    assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
    assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
}