Java Language
オラクルの公式コード標準

前書き

備考

命名規則

パッケージ名

• パッケージ名は、アンダースコアやその他の特殊文字を除くすべて小文字にする必要があります。
• パッケージ名は、開発者の会社のWebアドレスの逆権限部分で始まります。この部分は、プロジェクト/プログラム構造に依存するパッケージの下部構造に従うことができます。
• 複数形を使用しないでください。 java.lang.annotationではなくjava.lang.annotationsを使用する標準APIの規約に従ってください。
• 例： com.yourcompany.widget.button 、 com.yourcompany.core.api

クラス、インタフェース、列挙型の名前

• クラス名と列挙名は、通常、名詞でなければなりません。
• インタフェース名は通常、... ableで終わる名詞または形容詞でなければなりません。
• 大文字の各単語の最初の文字と大文字と小文字を混在させて使用します（例： CamelCase ）。
• 正規表現^[AZ][a-zA-Z0-9]*$一致してください。
• 省略形がロングフォームより広く使用されていない場合は、単語全体を使用し、略語の使用を避けてください。
• 短縮名が長いクラス名の一部である場合は、省略語を単語としてフォーマットします。
• 例： ArrayList 、 BigInteger 、 ArrayIndexOutOfBoundsException 、 Iterable 。

メソッド名

メソッド名は通常、動詞またはアクションの他の記述でなければなりません

• 正規表現^[az][a-zA-Z0-9]*$一致する必要があります。
• 小文字の最初の文字と大文字と小文字を混用してください。
• 例： toString 、 hashCode

変数

変数名は小文字の最初の文字と大文字と小文字が混在する必要があります

• 正規表現^[az][a-zA-Z0-9]*$一致する
• さらに推薦： 変数
• 例： elements 、 currentIndex

タイプ変数

関連する型変数が少ない単純なケースでは、大文字を1つ使用します。

• 正規表現^[AZ][0-9]?$一致する
• もしある文字が別のものよりも記述的であれば（例えば、 KとVのキーと値はマップにあり、 Rは関数の戻り値の型のように）、そうでなければT使います。
• 一文字型の変数が混乱するような複雑なケースでは、大文字で書かれた長い名前を使用し、アンダースコア（ _ ）を使用して単語を区切ります。
• 例： T 、 V 、 SRC_VERTEX

定数

内容（言語規則または慣例によって内容が不変であるstatic finalフィールド）は、大文字とアンダースコア（ _ ）で区切って単語を区切ります。

• 正規表現^[AZ][A-Z0-9]*(_[A-Z0-9]+)*$一致する
• 例： BUFFER_SIZE 、 MAX_LEVEL

命名に関するその他のガイドライン

• 外部スコープ内のメソッド、変数、型変数を隠す/隠すことは避けてください。
• 名前の冗長さをスコープのサイズに関連させます。 （たとえば、大きなクラスのフィールドにはわかりやすい名前を使用し、短命のローカル変数には短い名前を使用します）。
• public staticメンバーに名前を付けるときは、静的にインポートされると思われる場合は、識別子を自己記述的にします。
• 詳しい読書： ネーミングセクション （公式Javaスタイルガイド）

_{出典：OracleのJavaスタイルガイドライン}

Javaソースファイル

• すべての行は改行文字（LF、ASCII値10）で終わらなければならず、例えばCRやCR + LFで終わらなければなりません。

• 行末に空白が残っていない可能性があります。

• ソースファイルの名前は、パッケージのプライベートクラスのみを含むファイルであっても、その中に含まれるクラスの名前と.java拡張子が同じでなければなりません。これは、 package-info.javaなど、クラス宣言を含まないファイルには適用されません。

特殊文字

• LFとは別に空白文字はスペース（ASCII値32）のみです。これは、他の空白文字（たとえば、文字列や文字リテラルなど）をエスケープ形式で記述する必要があることに注意してください。

• \' 、 \" 、 \\ 、 \t 、 \b 、 \r 、 \f 、および\n （例えば、対応する進好まれるべきで\047 ）またはUnicode（例えば\u0027 ）文字をエスケープ。

• テストのために上記のルールに反する必要がある場合、テストは必要な入力をプログラムで生成する必要があります。

パッケージ宣言

package com.example.my.package;

パッケージの宣言は、行の推奨される最大長を超えているかどうかにかかわらず、行を折り返してはいけません。

インポートステートメント

// First java/javax packages
import java.util.ArrayList;
import javax.tools.JavaCompiler;

// Then third party libraries
import com.fasterxml.jackson.annotation.JsonProperty;

// Then project imports
import com.example.my.package.ClassA;
import com.example.my.package.ClassB;

// Then static imports (in the same order as above)
import static java.util.stream.Collectors.toList;

• インポート文をソートする必要があります...

  • ...主に非静的/静的で非静的なインポートを最初に使用します。
  • ...次の順番でパッケージ原点で二次的に
    • Javaパッケージ
    • javaxパッケージ
    • 外部パッケージ（例えば、org.xml）
    • 内部パッケージ（例：com.sun）
  • ...辞書順にパッケージとクラス識別子で3次

• インポートステートメントは、行の推奨される最大長を超えているかどうかにかかわらず、行の折り返しをしないでください。

• 未使用の輸入品は存在してはならない。

ワイルドカードのインポート

• ワイルドカードのインポートは一般的には使用されません。
• 多数の密接に関連するクラスをインポートする場合（例えば、数十の異なる「ノード」クラスを持つツリー上にビジターを実装する場合など）、ワイルドカードのインポートを使用できます。
• いずれの場合も、ファイルごとに複数のワイルドカードをインポートする必要はありません。

クラス構造

クラスメンバーの順序

クラスメンバーは次のように注文する必要があります。

1. フィールド（公開、保護、プライベート）
2. コンストラクタ
3. ファクトリメソッド
4. 他の方法（公的、保護された、私的の順）

主にアクセス修飾子または識別子によるフィールドとメソッドの順序付けは必要ありません。

この注文の例を以下に示します。

class Example {

    private int i;

    Example(int i) {
        this.i = i;
    }

    static Example getExample(int i) {
        return new Example(i);
    }

    @Override
    public String toString() {
        return "An example [" + i + "]";
    }

}

クラスメンバーのグループ化

• 関連するフィールドは一緒にグループ化する必要があります。
• ネストされた型は、最初の使用の直前に宣言することができます。それ以外の場合は、フィールドの前に宣言する必要があります。
• コンストラクタとオーバーロードされたメソッドは、機能性によってグループ化され、増加するアリティで順序付けされるべきです。これは、これらの構成要素の間の委任がコード内で下に流れることを意味します。
• コンストラクターは、他のメンバーを介さずにグループ化する必要があります。
• オーバーロードされたメソッドのバリアントは、他のメンバーを介さずにグループ化する必要があります。

修飾子

class ExampleClass {
    // Access modifiers first (don't do for instance "static public")
    public static void main(String[] args) {
        System.out.println("Hello World");
    }
}

interface ExampleInterface {
    // Avoid 'public' and 'abstract' since they are implicit
    void sayHello();
}

• 修飾語は次の順序で入力する必要があります

  • アクセス修飾子（ public / private / protected ）
  • abstract
  • static
  • final
  • transient
  • volatile
  • default
  • synchronized
  • native
  • strictfp

• 修飾子は暗黙のうちに書き出されるべきではありません。たとえば、インタフェースメソッドはpublicでもabstractでも宣言してはならず、ネストしたenumとインタフェースを静的宣言してはいけません。

• メソッドのパラメータとローカル変数は、読みやすさを向上させたり、実際の設計上の決定を文書化したりしない限り、 final宣言されるべきではありません。

• フィールドは、それらを変更可能な魅力的な理由がない限り、 finalに宣言する必要があります。

インデント

• インデントレベルは4つのスペースです 。
• インデントに使用できるのはスペース文字だけです。 タブはありません。
• 空行はインデントしてはいけません。 （これは、後続の空白の規則がないことによって暗示されます）。
• case行は4つのスペースでインデントする必要があり、ケース内のステートメントは別の4つのスペースでインデントする必要があります。

switch (var) {
    case TWO:
        setChoice("two");
        break;
    case THREE:
        setChoice("three");
        break;
    default:
        throw new IllegalArgumentException();
}

継続行をインデントする方法のガイドラインについては、「 折り返しステートメント」を参照してください。

ラッピングステートメント

• ソースコードとコメントは、通常、行ごとに80文字を超えてはならず、インデントを含めて1行に100文字を超えることはめったにありません。

  文字数制限は、ケースバイケースで判断する必要があります。本当に重要なのは、意味論的な "密度"と読みやすさです。線を無計画にすると読みにくくなります。同様に、「英雄的な試み」を80列に収めると、読みにくくなる可能性があります。ここで説明する柔軟性は、開発者がモニターの不動産を最大限に活用するのではなく、これらの極端な状況を回避できるようにすることを目指しています。

• URLまたはexampleコマンドはラップするべきではありません。

// Ok even though it might exceed max line width when indented.
Error e = isTypeParam
        ? Errors.InvalidRepeatableAnnotationNotApplicable(targetContainerType, on)
        : Errors.InvalidRepeatableAnnotationNotApplicableInContext(targetContainerType));

// Wrapping preferable
String pretty = Stream.of(args)
                      .map(Argument::prettyPrint)
                      .collectors(joining(", "));

// Too strict interpretation of max line width. Readability suffers.
Error e = isTypeParam
        ? Errors.InvalidRepeatableAnnotationNotApplicable(
                targetContainerType, on)
        : Errors.InvalidRepeatableAnnotationNotApplicableInContext(
                targetContainerType);

// Should be wrapped even though it fits within the character limit
String pretty = Stream.of(args).map(Argument::prettyPrint).collectors(joining(", "));

• 高い構文レベルでのラッピングは、より低い構文レベルでのラッピングよりも優先されます。

• 1行につき1つのステートメントが必要です。

• 継続行は、次の4つの方法のいずれかでインデントする必要があります

  • 変種1 ：前の行のインデントに対して8つの余分なスペースがあります。
  • 変種2 ：ラップされた式の開始列に対して8つの余分なスペース。
  • 変種3 ：前の兄弟表現にアライメントされる（それが継続行であることが明らかである限り）
  • 変種4 ：連鎖した式の前のメソッド呼び出しに揃えられました。

ラッピングメソッド宣言

int someMethod(String aString,
               List<Integer> aList,
               Map<String, String> aMap,
               int anInt,
               long aLong,
               Set<Number> aSet,
               double aDouble) {
    …
}

int someMethod(String aString, List<Integer> aList,
        Map<String, String> aMap, int anInt, long aLong,
        double aDouble, long aLong) {
    …
}

int someMethod(String aString,
               List<Map<Integer, StringBuffer>> aListOfMaps,
               Map<String, String> aMap)
        throws IllegalArgumentException {
    …
}

int someMethod(String aString, List<Integer> aList,
        Map<String, String> aMap, int anInt)
                throws IllegalArgumentException {
    …
}

• メソッドの宣言は、引数を垂直方向にリストするか、新しい行と+8余分なスペースを指定することでフォーマットできます
• throws節をラップする必要がある場合は、改行をthrows節の前に置き、関数の宣言に対して+8をインデントするか、または前の行に対して+8のどちらかで引数リストから目立つようにします。

式の折り返し

• 行が最大文字制限に近づく場合は、行を折り返すのではなく、常に複数の文/式に分割することを検討してください。
• 演算子の前に壊れます。
• の前に崩壊する。連鎖されたメソッド呼び出し。

popupMsg("Inbox notification: You have "
        + newMsgs + " new messages");

// Don't! Looks like two arguments
popupMsg("Inbox notification: You have " +
         newMsgs + " new messages");

空白

垂直空白

• 1つの空白行を使用して区切ります。

  • パッケージ宣言
  • クラス宣言
  • コンストラクタ
  • メソッド
  • 静的イニシャライザ
  • インスタンスイニシャライザ

• ...の論理グループを分離するために使用することができます

  • 輸入声明
  • フィールド
  • ステートメント

• 複数の連続する空白行は、関連するメンバーのグループを区切るためにのみ使用し、標準のメンバー間の間隔としては使用しないでください。

水平空白

• 単一のスペースを使用する必要があります...

  • 隣接する開閉記号とカッコからキーワードを区切るには
  • lambda式の矢印や拡張forループのコロン（ラベルのコロンの前ではない）のようなシンボルのようなバイナリ演算子と演算子の前後に、
  • //後にコメントを開始します。
  • 引数の区切りをカンマで区切って、forループの部分を区切るセミコロン。
  • キャストの閉じ括弧の後。

• 変数の宣言では、型と変数を整列させることは推奨されません。

変数宣言

• 宣言ごとに1つの変数（行ごとに最大でも1つの宣言）
• 配列の角括弧は、変数（ String args[] ）ではなく、型（ String[] args ）でなければなりません。
• ローカル変数を最初に使用する前に宣言し、できるだけ宣言の近くに初期化します。

注釈

宣言アノテーションは、アノテーションされている宣言とは別の行に置く必要があります。

@SuppressWarnings("unchecked")
public T[] toArray(T[] typeHolder) {
    ...
}

ただし、単一行のメソッドに注釈を付けるアノテーションは、可読性を向上させる場合は、メソッドと同じ行に配置することはできません。たとえば、次のように書くことができます。

@Nullable String getName() { return name; }

一貫性と可読性の観点から、すべての注釈を同じ行に置くか、各注釈を別々の行に置く必要があります。

// Bad.
@Deprecated @SafeVarargs
@CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

// Even worse.
@Deprecated @SafeVarargs
@CustomAnnotation public final Tuple<T> extend(T... elements) {
    ...
}

// Good.
@Deprecated
@SafeVarargs
@CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

// Good.
@Deprecated @SafeVarargs @CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

ラムダ式

Runnable r = () -> System.out.println("Hello World");

Supplier<String> c = () -> "Hello World";

// Collection::contains is a simple unary method and its behavior is
// clear from the context. A method reference is preferred here.
appendFilter(goodStrings::contains);

// A lambda expression is easier to understand than just tempMap::put in this case
trackTemperature((time, temp) -> tempMap.put(time, temp));

• 式ラムダは、単一行のブロックラムダよりも好ましい。
• メソッド参照はラムダ式よりも一般的に好まれるべきです。
• バインドされたインスタンスメソッド参照、または1より大きいarityを持つメソッドの場合、ラムダ式は理解しやすく、したがって好ましいものです。特に、メソッドの動作が文脈から明らかでない場合。
• パラメータの型は、読みやすさを向上させない限り省略してください。
• ラムダ式が数行以上にまたがる場合は、メソッドの作成を検討してください。

冗長なかっこ

return flag ? "yes" : "no";

String cmp = (flag1 != flag2) ? "not equal" : "equal";

// Don't do this
return (flag ? "yes" : "no");

• 読みやすさを向上させる場合は、冗長なグループ化括弧（評価に影響を与えない括弧）を使用できます。
• 冗長グループ化括弧は、一般的な演算子を含む短い式では省略しなければならないが、より長い式や括弧なしで優先順位と結合性が不明な演算子を含む式に含まれるべきである。非自明な条件を伴う三項式は、後者に属する。
• returnキーワードに続く式全体は、かっこで囲まれていてはいけません。

リテラル

long l = 5432L;
int i = 0x123 + 0xABC;
byte b = 0b1010;
float f1 = 1 / 5432f;
float f2 = 0.123e4f;
double d1 = 1 / 5432d;  // or 1 / 5432.0
double d2 = 0x1.3p2;

• longリテラルでは、大文字のL接尾辞を使用する必要があります。
• 16進リテラルでは、大文字A Fを使用する必要があります。
• 他のすべての接頭辞、接尾辞、および接尾辞は、小文字を使用する必要があります。

ブレース

class Example {
    void method(boolean error) {
        if (error) {
            Log.error("Error occurred!");
            System.out.println("Error!");
        } else { // Use braces since the other block uses braces.
            System.out.println("No error");
        }
    }
}

• カッティングはカッコ内の行ではなく、カレント行の最後に置く必要があります。

• ブロックが空でない限り、閉じ括弧の前に新しい行があるはずです（下記の短い書式を参照してください）

• 中括弧は、ifやloopの単一行のように、言語がオプションの場合でも推奨されます。

  • ブロックが複数の行（コメントを含む）にまたがっている場合は、中括弧が必要です。
  • if / elseステートメントのブロックの1つに中カッコがある場合は、もう一方のブロックも必要です。
  • ブロックが囲むブロックの最後に来る場合は、中括弧が必要です。

• do…whileループのelse 、 catchおよびwhileキーワードは、前のブロックの閉じ括弧と同じ行になります。

ショートフォーム

enum Response { YES, NO, MAYBE }
public boolean isReference() { return true; }

上記の推奨事項は、統一性を向上させるためのものです（親密度/可読性を向上させるため）。場合によっては、上記のガイドラインから逸脱した「短い書式」も読みやすく、代わりに使用することができます。これらのケースには、単純なenum宣言や簡単なメソッドやラムダ式などがあります。