Javaコードのフォーマットに関するGoogleのガイド

1.はじめに

このドキュメントでは、GoogleのJavaプログラミング言語でコーディングするための標準について説明します。Javaソースコードは、このドキュメントで説明されているすべてのルールを満たしている場合に限り、これらの標準に準拠していると見なされます。



このチュートリアルで取り上げるトピックは、コードフォーマットの美的側面だけでなく、他のタイプのコーディング規則や標準についても説明しています。ただし、このドキュメントは、主に私たちがどこでも従う厳格なルールの定義に焦点を当てており、（人間と機械ツールの両方によって）誤って実装される可能性のある推奨事項を提供していません。

1.1用語

このガイド全体を通して、次の用語が定義されています。

1. クラスという用語は、「通常の」クラス、列挙、インターフェイス、または注釈タイプ（@interface）を意味するために使用されます。
2. 用語クラス部材れる初期ブロックおよびコメントを除くすべての高レベルのクラスメンバーのため、あるネストされたクラス、フィールド、メソッド、またはコンストラクタを参照するために使用されます。
3. コメントという用語は、常に実装コメントを指します。「ドキュメントコメント」というフレーズは使用しませんが、代わりに「Javadoc」という用語を使用します。

残りの用語は、このマニュアル全体で必要に応じて提供されます。

1.2ガイドノート

このドキュメントのコード例は、チュートリアルで使用されていますが、フォーマットに対する唯一の正しいスタイルのアプローチを示しているわけではありません。

2.ソースファイル。基礎

2.1ファイル名

ソースファイル名は、そこに存在する1つの特定のトップレベルクラスの名前で構成されます。名前は大文字と小文字が区別され、.java拡張子で終わります

2.2ファイルエンコーディング：UTF-8

コード付きのファイルはUTF-8でエンコードされます。

2.3特殊文字

2.3.1スペース文字

行末の文字シーケンスとは別に、水平ASCIIスペース文字（0x20）は、ソースファイルで見つかった唯一の区切り文字です。だということだ：

1. 文字および文字列リテラル内の他のすべての空白文字はエスケープされます
2. タブ文字はインデントには使用されません

2.3.2特別なエスケープシーケンス

特別なエスケープシーケンス（\ b、\ t、\ n、\ f、\ r、\ "、\ '、および\\）がある文字ごとに、対応する8進値（たとえば、\ 012）の代わりにそれを使用することをお勧めします。 ）またはUnicodeコード（例：\ u000a）。

2.3.3非ASCII文字

非ASCII文字の場合は、Unicode文字（たとえば、∞）または同等のエスケープシーケンス（たとえば、\ u221e）を使用します。コードをより理解しやすく読みやすくするシンボルを優先して選択します。

Unicodeエンコーディングでエスケープ文字を使用する場合、および有効なUnicode文字を使用する場合は、そのようなコードに説明コメントを付けることを強くお勧めします。

一部のプログラムが非ASCII文字を正しく処理できないことを恐れて、コードを読みにくくしないでください。これが発生した場合、そのようなプログラムは正しく機能せず、修正する必要があります。

3.ソースファイルの構造

ソースファイルは、次の要素で構成されています（示されている順序で）。

1. ライセンスまたは著作権情報（ある場合）
2. パッケージ宣言
3. 輸入の宣言
4. クラス宣言

正確に1つの空白行が、存在する各セクションを区切ります。

3.1ライセンスまたは著作権情報（ある場合）

ライセンスまたは著作権情報は、それが参照するファイルに含まれている必要があります。

3.2パッケージ宣言

パッケージは改行なしで宣言されます。線幅の制限（セクション4.4）は、パッケージ宣言には適用されません。

3.3インポート宣言

3.3.1インポート宣言のワイルドカード

*（ワイルドカード）文字は、静的かどうかに関係なく、インポートを宣言するときに使用されません。

3.3.2改行

インポートは改行なしで宣言されます。線幅の制限はありません。

3.3.3順序と間隔

輸入品は次のように注文されます。

1. すべての静的インポートは1つのブロックに配置され、グループ化されます
2. すべての非静的インポートは別のブロックに配置されます

静的インポートと非静的インポートの両方が宣言されている場合、これらのブロックは空の行で区切る必要があります。それらの間に他の空白行があってはなりません。



各ブロック内で、インポートされたクラスがASCII文字のソート順にリストされます。

3.3.4ネストされたクラスの静的インポート

静的インポートは、静的にネストされたクラスには使用されません。このようなクラスは、通常のインポート宣言でインポートされます。

3.4クラス宣言

3.4.1正確に1つのトップレベルクラスが宣言されます

各トップレベルクラスは、独自のソースファイルにあります。

3.4.2クラスの内容の順序付け

クラスのメンバーと初期化ブロックを配置する順序は、コードの理解のしやすさに大きな影響を与える可能性があります。いずれにせよ、これには簡単で正しいレシピはありません。クラスが異なれば、コンテンツの配置も異なります。



重要なことは、コードを読んでいるプログラマーがそれを説明できるように、各クラスにはコンテンツの論理的な順序があるということです。

3.4.2.1オーバーロードされたコードは分割しないでください

クラスに同じ名前の複数のコンストラクターまたはメソッドがある場合、それらの間に他のコードを挿入せずに順番に配置する必要があります。

4.フォーマット

用語

クラス、メソッド、またはコンストラクターの本体はブロック構造です。



セクション4.8.3.1によると、任意の配列初期化子もブロック構造と見なすことができることに注意してください。

4.1中括弧

4.1.1中括弧は、使用できる場所で使用されます

式の本体が空であるか、コードが1行しかない場合でも、中括弧はif、else、for、while、およびdo-whileで使用されます。

4.1.2非空白ブロック：K＆Rスタイル

中括弧は、空でないブロックとブロック構造のKernighanとRitchie（「エジプトの括弧」）のスタイルに従って配置されます（わかりやすくするために、これらのルールを示す小さなコードを追加することにしました-翻訳者のメモ）：

• 開始括弧の前に改行は行われません。

// 
if (true) { 

// 
if (true)
{

• 改行は、開始括弧の後に実行されます。

// 
while (true) {
  // code

// 
while (true) { // code

• 閉じ括弧の前に改行が行われます。

// 
for () {
  // code
}

// 
while (true) { /* code */ }

// 
if (true) {
  /* code */ }

• 改行は、括弧がメソッド、コンストラクター、または非匿名クラスの式または本体を終了する場合にのみ、括弧を閉じる後に行われます。括弧の後にelse、catch、またはsemicolonが続く場合、改行は行われません。

正しく実行されたルールの例：

return () -> {
  while (condition()) {
    method();
  }
};

return new MyClass() {
  @Override public void method() {
    if (condition()) {
      try {
        something();
      } catch (ProblemException e) {
        recover();
      }
    } else if (otherCondition()) {
      somethingElse();
    } else {
      lastThing();
    }
  }
};

列挙のいくつかの例外はセクション4.8.1に記載されています

4.1.3空のブロックは圧縮できます

空のブロックまたは空のブロック構造は、K＆Rスタイルに従うことができます（セクション4.1.2で説明）。このようなブロックは、{}内に文字や改行を入れずに、開いた直後に閉じることもできます。このルールは、ブロックがif-elseまたはtry-catch-finallyを含むマルチブロック式の一部である場合には適用されません。



例：

// 
void doNothing() {}

//  
void doNothingElse() {
}

// :       
try {
  doSomething();
} catch (Exception e) {}

4.2インデント用の2つのスペース

新しいブロックまたはブロック構造が開かれるたびに、右側のオフセットが2スペースずつ増加します。ブロックが終了すると、コードの次の行の開始が前のオフセットレベルにシフトされます。オフセットレベルは、ブロックとそのブロック内のコメントの両方に適用されます（セクション4.1.2の例を参照）。

4.3行ごとに1つの式

各式は改行で終わります。

4.4線幅を100文字に制限する

Javaコードは、行幅が100文字に制限されています。「文字」とは、Unicode要素のいずれかを指します。以下に説明する場合を除き、幅の制限を超える各行は、セクション4.5で説明するように折り返す必要があります。



例外：

1. , (, URL Javadoc JSNI- )
2. package import (. 3.2 3.3)
3. ,

4.5

同じ行にある可能性のあるコードが複数の行に分割される場合、この現象は改行と呼ばれます。



すべての状況で改行をどのように実行するかを正確に決定する、一般的に受け入れられている明確な式はありません。非常に多くの場合、同じコードで行を分割する方法はいくつかあります。



通常、折り返しは線幅のオーバーフローを回避するために行われます。ただし、コードが許可された幅内にとどまる場合でも、作成者の決定により、新しい行にラップすることができます。

ヘルパーメソッドまたはローカル変数を割り当てると、コードをラップせずに線幅オーバーフローの問題を解決できます

4.5.1転送先

改行の最初のガイドラインは次のように述べています。より高い構文レベルで改行を行うことが望ましいです。また：



1。割り当てられていないステートメントで行が途切れる場合、文字の前で区切りが行われます。



このルールは、次の「オペレーターのような」文字にも適用されます。

• 分割点「。」
• 参照メソッド「::」の二重コロン
• 括弧内のアンペアサンド一​​般<TはFoo＆Barを拡張>
• キャッチブロックの区切り文字（FooException | BarException e）

2.文字列が割り当てステートメントでラップされる場合、ラップは通常、文字の後に行われますが、別の解決策



も受け入れられます。これは、for-eachループのコロンにも適用されます。



3.改行時のメソッドまたはコンストラクターの名前は、開始括弧 "（"に付加されたままになり



ます。4。改行時のコンマ "、"は、その前の要素に残り



ます。その本体は、中括弧のない単一の式で構成されています。

MyLambda<String, Long, Object> lambda =
    (String label, Long value, Object obj) -> {
        ...
    };

Predicate<String> predicate = str ->
    longExpressionInvolving(str);

改行の主な目的は、コードを明確にすることですが、必ずしも最小行数である必要はありません。

4.5.24つ以上のスペースによるオフセットラインの継続

行が途切れるとき、後続の各サブストリング（各行の続き）は、前のサブストリングに対して少なくとも4スペースシフトされます。



複数の行の続きがある場合、オフセットは作成者の要求に応じて4スペース以内で変更できます。原則として、2つの線延長は、構文的に並列な要素で始まる場合に限り、同じオフセットを持つことができます。



セクション4.6.3は、さまざまな量のスペースを使用して、前の行に対してコードポイントを整列させるためのガイダンスを提供します。

4.6スペースとインデント

4.6.1インデント

1つの空の行が常に配置されます



。1。連続するメンバーまたはクラス初期化子の間：フィールド、コンストラクター、メソッド、ネストされたクラス、静的および動的初期化ブロック

• 例外：2つの連続するフィールド間の空の行（フィールド間にコードはありません）はオプションです。空白行は、必要に応じてフィールドを論理的にグループ化するために使用されます
• 例外：enumクラス定数間の空白行（セクション4.8.1を参照）

2.このドキュメントの他のセクションとの整合性（セクション3やセクション3.3など）



空白行は、コードを論理的なサブセクションに編成する式の間など、コードの読みやすさを向上させるためにあらゆる場所で使用することもできます。クラスの最初のメンバー、初期化ブロックの前、最後のメンバー、またはクラスの初期化ブロックの後の空の文字列は推奨されませんが、禁止されていません。



複数の連続した空白行は許可されますが、必須または推奨されません。

4.6.2スペース

言語自体またはこのドキュメントの他のルールの要件、およびリテラルとコメント（Javadocを含む）をカウントしないこととは別に、ASCIIテーブルからの単一のスペースは次の場所にのみ存在できます。1。if、



などの予約済みの単語を区切る場合forまたはcatchおよび



2に続く開始括弧「（」。elseまたはcatchなどの予約済み単語を区切る場合、および



3に続く終了中括弧「}」。開始中括弧の前「 {"、2つの状況を除いて：

• @SomeAnnotation（{a、b}）
• 文字列[] [] x = {{"foo"}}; -{{の間のスペースは、以下の第8項に従って必要ありません

4.バイナリ演算子またはターナリ演算子のいずれかの側



このルールは、次の演算子にも適用されます。

• アンペアとアングルブラケットの内側：<TはFoo＆Barを拡張します>
• 複数の例外を含むcatchブロックの区切り文字：catch（FooException | BarException e）
• for-eachのコロン "："
• ラムダ式の矢印:(文字列str）-> str.length（）

ただし、このルールはオペレーターには適用されません。

• Object :: toStringとして記述される参照メソッドの二重コロン "::"
• object.toString（）として記述される区切りドット「。」

5。「、：;」の後 または、タイプ



6にキャストする場合は閉じ括弧「）」。同じコード行にコメントを作成する場合は、二重前方スラッシュ「//」の両側。複数のスペースを使用できますが、ここでは必須ではありません



。7。型宣言と変数名の間：

List<String> list

8.オプション：配列初期化子の括弧内

new int [] {5、6}およびnew int [] {5、6}は両方とも有効です



。9。型注釈と[]または...の間



このルールでは、スペースの有無は必要ありません。行の開始または終了。内部スペースにのみ適用されます。

4.6.3水平方向の位置合わせは必要ありません

用語

水平方向の配置とは、コードにさまざまな数の余分なスペースを追加して、特定の要素が前の行の他の要素の下に表示されるようにすることです。



この方法は許可されていますが、このガイドでは必須ではありません。また、すでに適用されているコードの部分でアライメントを維持する必要もありません。



位置合わせがある場合とない場合の例：

private int x; // 
private Color color; //   

private int   x;      // ,     
private Color color;  //    

位置合わせによりコードの読みやすさが向上しますが、将来そのようなコードを維持する際に問題が発生します。1行だけ変更したいとします。この変更により、以前に受け入れられたコードのフォーマットが破損する可能性があります。これは許容範囲です。しかし、おそらく、プログラマー（おそらくあなた）は隣接する行のスペースの数を調整し始め、それが一連​​の修正全体をトリガーする可能性があります。1つの行を変更すると、（最悪の場合）無意識の労働の「爆発波」が引き起こされる可能性があります。または、せいぜい、バージョン履歴の情報を歪め、コードの読みやすさを損ない、マージの競合を悪化させます。

4.7グループ化ブラケットをお勧めします

コードの作成者とレビュー担当者が、コードが括弧なしで誤って解釈される可能性がなく、括弧によって読みやすくならないことに同意する場合にのみ、グループ化括弧を省略してください。コードを読んだ人がJava演算子の優先順位テーブル全体を記憶していると信じる理由はありません。

4.8特別なデザイン

4.8.1列挙クラス

列挙定数に続く各コンマの後の改行はオプションです。余分な空白行（通常は1行のみ）も許可されます。このようなコードの例を次に示します。

private enum Answer {
  YES {
    @Override public String toString() {
      return "yes";
    }
  },

  NO,
  MAYBE
}

定数を説明するメソッドとコメントのない列挙クラスのコードは、配列初期化子として表すことができます（セクション4.8.3.1を参照）。

private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }

列挙型はクラスであるため、クラスに適用される他のすべてのルールをそれらに適用する必要があります。

4.8.2変数宣言

4.8.2.1宣言ごとに1つの変数

各変数（フィールドまたはローカル）は、一度に1つだけ宣言されます。inta、bなどの宣言。使用されません。



例外：forループのヘッダーで複数の変数宣言を使用できます。

4.8.2.2必要なときに変数を宣言する

ローカル変数は、ブロックまたはブロック構築の開始時に宣言する必要はありません。逆に、ローカル変数は、スコープを最小化するために最初に使用される直前に宣言する必要があります。通常、ローカル変数は宣言時または宣言直後に初期化されます。

4.8.3アレイ

4.8.3.1配列初期化子は「ブロック」にすることができます

任意の配列は、ブロック構造であるかのように初期化できます。たとえば、次のコードはすべて有効です（例のリストは完全ではありません）。

new int[] {
  0, 1, 2, 3
}
                        
new int[] {
  0, 1,
  2, 3
}

new int[]
    {0, 1, 2, 3}

new int[] {
  0,
  1,
  2,
  3
}

4.8.3.2Cスタイルの配列宣言なし

角括弧は、変数の後ではなく、タイプの後に配置されます。String[] args、String args []ではありません。

4.8.4スイッチステートメント

用語

ステートメントの1つ以上のグループは、スイッチブロック内にあります。各グループは、1つ以上のラベル（FOO：とデフォルト:)の後に1つ以上のステートメント（または、最後のグループの場合はなし）で構成されます。

4.8.4.1オフセット

他のブロックと同様に、スイッチブロックの内容は2スペースオフセットされます。



スイッチブロックラベルの後に改行が作成され、ブロックが開かれたときと同じように、オフセットが2スペース増加します。次の各ラベルは、ブロックを閉じるときと同様に、前のオフセットレベルに戻ります。

4.8.4.2パススルーがコメント化されています

ブロック内では、ステートメントの各グループは、スイッチでスケジュールより早く終了するか（break、continue、return、または例外のスローを使用）、コードの実行が次のグループで続行されるか続行できるかを示すコメントでマークされます。通過（通常は//フォールスルー）のアイデアを伝えるコメントで十分です。このコメントは、スイッチブロックの最後のグループでは必要ありません。例：

switch (input) {
  case 1:
  case 2:
    prepareOneOrTwo();
    // fall through
  case 3:
    handleOneTwoOrThree();
    break;
  default:
    handleLargeNumber(input);
}

コメントはケース1の後に配置されるのではなく、ステートメントグループの最後にのみ配置されることに注意してください。

4.8.4.3常にデフォルトを使用する

switchステートメントには、コードが含まれていない場合でも、デフォルトのラベルが含まれている必要があります。



例外：enumタイプのスイッチブロックは、そのタイプのすべての可能な値をカバーする明示的なケースが含まれている場合、デフォルトを使用しない場合があります。これにより、IDEまたはその他の静的分析ツールは、一部のケースがカバーされていないという警告を発行できます。

4.8.5注釈

クラス、メソッド、またはコンストラクターに適用される注釈は、docブロックの直後に続きます。各注釈は、独自の行に示されます（つまり、行ごとに1つの注釈）。これらの改行は改行ではないため（セクション4.5を参照）、インデントレベルは増加しません。例：

@Override
@Nullable
public String getNameIfPresent() { ... }

例外：パラメータのない単一の注釈を最初の署名行と一緒に表示できます。次に例を示します。

@Override public int hashCode() { ... }

フィールドに適用された注釈もdocブロックの直後に表示されますが、この場合、複数の注釈（パラメーター化されている可能性があります）を1行にリストできます。次に例を示します。

@Partial @Mock DataLoader loader;

パラメータ、ローカル変数、またはタイプの注釈をフォーマットするための特別な規則はありません。

4.8.6コメント

このセクションは、実装コメント専用です。Javadocについては、セクション7で個別に説明します。



改行の前には任意の数のスペースを付け、その後に実装コメントを付けることができます。このコメントにより、行は空になりません。

4.8.6.1ブロックコメントスタイル

ブロックコメントのインデントレベルは、周囲のコードと同じです。ブロックコメントは、/ *…* /または//…のいずれかになります。/*…*/のような複数行のコメントの場合、後続の行は*で始まり、前の行の*に揃える必要があります。

/*
 * This is          // And so           /* Or you can
 * okay.            // is this.          * even do this. */
 */

コメントは、アスタリスクやその他の記号で表される長方形で囲まれていません。

複数行のコメントを作成するときに、自動コードフォーマッタで必要に応じて（段落のスタイルで）行を分割する場合は、/ * ... * /スタイルを使用します。ほとんどのフォーマッタは、1行のコメントブロックではこれを行うことができません//..。

4.8.7修飾子

クラスおよびフィールド修飾子が存在する場合は、Java言語仕様で推奨されている順序で表示されます。

public protected private abstract default static final transient volatile synchronized native strictfp

4.8.8数値リテラル

長いタイプは、小文字ではなく大文字のLを使用します（数字の1と混同しないように）。たとえば、300_000_000lではなく300_000_000Lです。

5.ネーミング

5.1すべての識別子の一般規則

識別子はASCIIの文字と数字のみを使用し、以下に示す場合は下線を使用します。



したがって、すべての有効な識別子名は、通常の式\ w +（1回以上出現する英数字）と一致します。



name_、mName、s_name、kNameなどの特別なサフィックスまたはプレフィックスを使用する名前は、このチュートリアルのスタイルに準拠していません。

5.2さまざまなタイプの識別子のルール

5.2.1パッケージ名

パッケージ名は、camelCaseや下線なしで小文字で記述する必要があります。



正解：com.example.deepspace

不正解：com.example.deepSpaceまたはcom.example.deep_space

5.2.2クラス名

クラス名はUpperCamelCaseスタイル（大文字の最初の文字）で書かれています。



クラス名は通常、名詞または名詞句です。たとえば、CharacterまたはImmutableListです。



インターフェイス名は、名詞または名詞句（たとえば、リスト）にすることもできますが、形容詞または形容詞の組み合わせ（たとえば、読み取り可能）にすることもできます。



注釈タイプに名前を付けるための特定の規則や確立された規則はありません。



テストクラスの名前は、テストしているクラスの名前で始まり、Testで終わります。たとえば、HashTestまたはHashIntegrationTestです。

5.2.3メソッド名

メソッド名はlowerCamelCaseスタイルで記述されます。



メソッド名は通常、動詞または動詞句です。たとえば、sendMessageまたはstop。



JUnitテストメソッド名でアンダースコアを使用して、名前内の論理コンポーネントを区切ることができます。さらに、各コンポーネントはlowerCamelCaseスタイルで記述されています。典型的なパターンは次のとおりです。

<methodUnderTest>_<state>, , pop_emptyStack

テストメソッドに名前を付ける正しい方法は1つではありません。

5.2.4定数名

定数はCONSTANT_CASEスタイルで名前が付けられます。すべての文字は大文字で、各単語は下線で区切られています。しかし、定数とは正確には何ですか？



定数は、内容が不変である静的な最終フィールドであり、目に見える副作用のないメソッドです。これは、プリミティブ、文字列、不変型、および不変型の不変コレクションに適用されます。オブジェクトの観察可能な状態が変化する可能性がある場合、それは一定ではありません。オブジェクトを決して変更しないという単純な意図だけでは十分ではありません。



例：

// 
static final int NUMBER = 5;
static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");
static final ImmutableMap<String, Integer> AGES = ImmutableMap.of("Ed", 35, "Ann", 32);
static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

//  
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set<String> mutableCollection = new HashSet<String>();
static final ImmutableSet<SomeMutableType> mutableElements = ImmutableSet.of(mutable);
static final ImmutableMap<String, SomeMutableType> mutableValues =
    ImmutableMap.of("Ed", mutableInstance, "Ann", mutableInstance2);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

定数名は通常、名詞または名詞句です。

5.2.5非定数フィールドの名前

定数ではない（静的かどうかに関係なく）フィールドの名前は、lowerCamelCaseスタイルで記述されます。



このようなフィールドの名前は通常、名詞または名詞句です。たとえば、computedValuesまたはindex。

5.2.6パラメータ名

パラメータ名はlowerCamelCaseスタイルで記述されています。



パブリックメソッドでは、1文字のパラメータ名は避けてください。

5.2.7ローカル変数名

ローカル変数名はlowerCamelCaseスタイルで記述されます。



それらは最終的で不変ですが、ローカル変数は定数とは見なされないため、定数と同じスタイルで記述しないでください。

5.2.8タイプ変数の名前

各タイプ変数は、次の2つのスタイルのいずれかに従って名前が付けられます。

• 単一の大文字。その後に通常の番号（E、T、X、T2など）を続けることができます。
• クラス名（セクション5.2.2を参照）の後に大文字のT（例：RequestT、FooBarT）が続く形式の名前。

5.3キャメルスタイル（camelCase）

省略形や「IPv6」や「iOS」などの非定型表現の場合など、英語のフレーズをラクダスタイルに変換する方法が複数ある場合があります。



予測可能性を高めるために、このガイドでは次の（例示的な）スキームについて説明します。



名前の元の形式から開始し



ます。1。フレーズを通常のASCIIに変換し、すべてのアポストロフを削除します。たとえば、「ミュラーのアルゴリズム」は「ミュラーのアルゴリズム」に変換できます



。2。結果を単語に分割し、スペースと残りの句読点（通常はハイフン）を破棄します。

• 推奨事項：単語がすでに通常の「キャメル」スタイルで共通の形式を持っている場合は、それを構成要素に分割します（たとえば、「AdWords」は「広告単語」に変換されます）。「iOS」のような単語は、実際にはラクダスタイルではないことに注意してください。規則に準拠していないため、この推奨事項は適用されません。

3.次に、すべてを小文字（省略形を含む）に変換してから、最初の文字を大文字に変換します。

• ...すべての単語でUpperCamelCaseスタイルを実現する、または
• ... lowerCamelCaseスタイルを実現する最初のものを除くすべての単語で

4.最後に、すべての単語を1つの識別子に連結します。



元の単語の大文字と小文字はほとんど完全に無視されることに注意してください。



例：



*許可されていますが、推奨されていません。



注：英語の一部の単語では、ハイフンがあいまいに使用されています。たとえば、「nonempty」と「non-empty」の両方が正しいため、メソッド名checkNonemptyとcheckNonEmptyも正しいです。

6.プログラミングの練習

6.1常に@Overrideアノテーションを使用する

メソッドは、実際にオーバーライドされるたびに@Overrideアノテーションでマークされます。これは、親クラスのメソッドをオーバーライドする子孫クラスのメソッドと、スーパーインターフェイスのメソッドをオーバーライドするインターフェイスのメソッドの両方に適用されます。



例外：親メソッドが@Deprecated注釈でマークされている場合、注釈は省略できます。

6.2キャッチされた例外を無視しないでください

キャッチされた例外に応答してアクションを実行する必要がない状況が発生することは非常にまれです（一般的な解決策は、ログに記録するか、「不可能」と見なされる場合は、例外をAssertionErrorとしてスローすることです）。



以下は、catchブロックでアクションを実行しないことが本当に適切な場合の説明コメント付きの例です。

try {
  int i = Integer.parseInt(response);
  return handleNumericResponse(i);
} catch (NumberFormatException ok) {
  // it's not numeric; that's fine, just continue
}
return handleTextResponse(response);

例外：テストでは、テスト名が予期されている場合、または名前が期待値で始まる場合、キャッチされた例外は無視され、コメントが外されることがあります。以下は、テスト対象のコードが予期されたタイプの例外をスローすることを示す非常に一般的なイディオムであるため、ここでコメントは必要ありません。

try {
  emptyStack.pop();
  fail();
} catch (NoSuchElementException expected) {
}

6.3静的メンバーの場合、クラス名を使用します

クラスオブジェクトへの参照やこのオブジェクトを返す式ではなく、クラス名を介して静的クラスのメンバーを参照する必要があります。

Foo aFoo = ...;
Foo.aStaticMethod(); // 
aFoo.aStaticMethod(); // 
somethingThatYieldsAFoo().aStaticMethod(); //  

6.4ファイナライザーを使用しないでください

Object.finalizeメソッドをオーバーライドする必要があることは非常にまれです。



ヒント：



これは行わないでください。本当に必要な場合は、最初に効果的なJavaアイテム7を読み、完全に理解してから、ファイナライザーを避けてください。

7. Javadoc

7.1フォーマット

7.1.1メインフォーム

Javadocブロックの単純なフォーマットは、次の例に従います。

/**
 * Multiple lines of Javadoc text are written here,
 * wrapped normally...
 */
public int method(String p1) { ... }

...または1行で：

/** An especially short bit of Javadoc. */

単純な形式は常に適用可能です。1行のフォームは、Javadocブロック全体（コメントマーカーを含む）が1行に収まる場合に適用できます。これは、ブロックに@returnなどのタグがない場合にのみ適用されることに注意してください。

7.1.2段落

1つの空白行、つまり、整列された先頭のアスタリスク（*）のみを含む行が、段落間およびブロックタググループの前に表示されます（存在する場合）。最初の段落を除くすべての段落には、最初の単語の直前に<p>が含まれ、後にスペースはありません。

7.1.3ブロックタグ

すべてのブロックタグは、@ param、@ return、@ throws、@ deprecatedの順序であり、これらの4つのタイプが空の説明とともに存在することはありません。ブロックタグが1行に収まらない場合、継続行は@から4つ（またはそれ以上）のスペースでインデントされます。

7.2最終スニペット

各Javadocブロックは、短い要約スニペットで始まります。このスニペットは非常に重要です。クラスやメソッドのインデックスなど、特定のコンテキストに表示される唯一のテキストです。



このスニペットは、全文ではなく、名詞または動詞のフレーズです。{@code Foo}は...またはこのメソッドは...を返します。また、レコードの保存のような完全な肯定文を形成することもありません。ただし、このパッセージは、完全な文であるかのように大文字で区切られています。



ヒント：/ ** @ return顧客ID * /のような単純なJavadocを作成するのはよくある間違いです。これは正しくないため、次のように修正する必要があります/ **顧客IDを返します。* /。

7.3Javadocが適用される場合

Javadocは、以下で説明する場合を除いて、少なくともすべてのパブリッククラス、およびそのようなクラスのすべてのパブリックおよび保護されたメンバーに存在します。

セクション7.3.4、オプションのJavadocで説明されているように、追加のJavadocが存在する場合があります。

7.3.1例外：自分自身を説明するメソッド

Javadocは、「fooを返す」以上のことを本当に言えない場合のgetFooのような単純で明白なメソッドのオプションです。



重要：一般の読者が必要とする可能性のある関連情報を省略することを正当化するために、この例外を参照することは不適切です。



たとえば、getCanonicalNameという名前のメソッドの場合、ドキュメントを省略しないでください（メソッド名に/ **正規名のみが返されることを正当化してください。* /）コードを読んでいる平均的な人が、「正規名」という用語の意味を疑うことさえできない場合！

7.3.2例外：オーバーライド

Javadocは、スーパークラス（またはスーパーインターフェイス）のメソッドをオーバーライドするメソッドを常に伴うとは限りません。

7.3.4オプションのJavadoc

他のクラスやメンバーには、必要に応じて、または必要に応じてJavadocが付属しています。



クラスまたはメンバーの一般的な目的または動作を定義するために実装コメントが使用される場合は常に、そのコメントはJavadocとして書き込まれます（/ **を使用）。



オプションのJavadocは、セクション7.1.2、7.1.3、および7.2のフォーマット規則に従う必要はありませんが、これはもちろん推奨されます。



この翻訳は、私たちのブログでも入手できます。