Google Javaスタイルガイド

1はじめに

このドキュメントは、Java™プログラミング言語におけるソースコードのGoogleのコーディング標準の完全な定義とし Javaソースファイルは、ここに記載されている規則に準拠している場合にのみ、googleスタイルであると記述されます。

他のプログラミングスタイルガイドと同様に、カバーされている問題は、フォーマットの審美的な問題だけでなく、他のタイプの規則や符号化標準にも及んでいます。 しかし、このdocumentfocusesは、主に我々は普遍的に従うハードと高速のルールに、andavoidsは明らかに(人間やツールによってかどうか)強制力ではないアドバイスを与えています。

1.1用語ノート

このドキュメントでは、特に明確にしない限り、

  1. クラスという用語は、”通常の”クラス、列挙型クラス、インターフェイス、または注釈型(@interface)を意味するために包括的に使用されています。
  2. (クラスの)メンバーという用語は、ネストされたクラス、フィールド、メソッド、またはコンストラクタを意味するために包括的に使用されます; つまり、初期化子とコメントを除くクラスのすべてのトップレベルの内容です。
  3. コメントという用語は、常に実装コメントを指します。 私たちは、”documentation comments”という語句を使用せず、代わりに一般的な用語”Javadoc”を使用しています。”

その他の”用語に関する注意事項”は、ドキュメント全体に時折表示されます。

1.2ガイドノート

このドキュメントのコード例は非規範的です。 つまり、例はGoogleスタイルであるが、コードを表現する唯一のスタイリッシュな方法を説明していない可能性がある。 例で行われたオプションの書式設定の選択は、ルールとして強制すべきではありません。

2ソースファイルの基本

2.1ファイル名

ソースファイル名は、含まれているトップレベルクラスの大文字と小文字を区別する名前(正確には1つ)と、.java拡張子で構成されています。2.2ファイルエンコーディング:UTF-8

ソースファイルはUTF-8でエンコードされます。

2.3特殊文字

2.3.1空白文字

行終端文字シーケンスを除いて、ASCII水平spacecharacter(0x20)は、ソースファイル内のどこに表示される唯一の空白文字です。 これはそれを意味します:

  1. All other whitespace characters in string and character literals are escaped.
  2. Tab characters are not used for indentation.

2.3.2 Special escape sequences

For any character that has a special escape sequence(\b\t\n\f\r\"\' and\\), that sequenceis used rather than the corresponding octal(e.g. \012) or Unicode(e.g. \u000a)エスケープします。残りの非ASCII文字には、実際のUnicode文字(例:)または同等のUnicodeエスケープ文字(例:\u221e)が使用されます。 選択は、コードを読みやすく理解しやすくすることにのみ依存しますが、Unicode escapesoutside文字列リテラルとコメントは強くお勧めしません。ヒント:Unicodeエスケープの場合、およびactualUnicode文字が使用されている場合でも、説明コメントが非常に役立つことがあります。

例:

議論
String unitAbbrev = "μs"; ベスト:コメントなしでも完全にクリア。/td>
String unitAbbrev = "\u03bcs"; // "μs" 許可されていますが、これを行う理由はありません。td>
String unitAbbrev = "\u03bcs"; // Greek letter mu, "s" 許可されていますが、ぎこちなく、間違いを起こしやすいです。/td>
String unitAbbrev = "\u03bcs"; 貧しい:読者はこれが何であるか分かりません。/td>
return '\ufeff' + content; // byte order mark 良い: 印刷できない文字にはエスケープを使用し、必要に応じてコメントを使用します。

ヒント:一部のプログラムが非ASCII文字を適切に処理できない恐れから、コードを読みにくくしないでください。 それが起こるべきであれば、thoseprogramsは壊れており、それらは修正されなければなりません。

3ソースファイルの構造

ソースファイルは、次の順序で構成されます:

  1. ライセンスまたは著作権情報、存在する場合
  2. パッケージステートメント
  3. インポートステートメント
  4. 正確に一つのトップレベルのクラス

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

3.1ライセンスまたは著作権情報が存在する場合

ライセンスまたは著作権情報がファイルに属している場合は、ここに属します。

3.2パッケージ文

パッケージ文は行折り返しではありません。 列の制限(セクション4.4,列の制限:100)は、パッケージステートメントには適用されません。

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

3.3。1ワイルドカードインポートなし

ワイルドカードインポートは、静的またはそれ以外の場合は使用されません。

3.3.2行折り返しなし

インポートステートメントは行折り返しではありません。 列の制限(セクション4.4,列の制限:100)は、importstatementsには適用されません。

3.3.3順序と間隔

インポートは次のように順序付けられます。

  1. 単一のブロック内のすべての静的インポート。
  2. 単一のブロック内のすべての非静的インポート。

静的インポートと非静的インポートの両方がある場合、単一の空白行で2つのブロックが分離されます。 Import文の間に他の空白行はありません。

各ブロック内で、インポートされた名前はASCIIソート順で表示されます。 (注:これは、’のため、ASCIIソート順にあるimport文と同じではありません。’前に並べ替え’;’。)

3.3.4クラスの静的インポートはありません

静的インポートは、静的ネストされたクラスには使用されません。 それらはと輸入されます通常の輸入。

3.4クラス宣言

3.4.1トップレベルクラス宣言

各トップレベルクラスは、独自のソースファイルに存在します。3.4.

3.4.2クラスの内容の順序

あなたのクラスのメンバーと初期化子のために選択した順序は、大きな効果onlearnabilityを持つことができます。 しかし、それを行う方法のための単一の正しいレシピはありません。

重要なのは、各クラスが何らかの論理的な順序を使用していることです。 たとえば、新しいメソッドは、クラスのendofに習慣的に追加されるだけでなく、logicalorderingではない”日付による時系列追加”の順序付けが行われます。

3.4.2.1オーバーロード: never split

クラスが複数のコンストラクタ、または同じ名前の複数のメソッドを持つ場合、これらは連続的に表示され、間に他のコードはありません(プ

4書式設定

用語注:ブロックのような構造は、クラス、メソッド、またはコンストラクタの本体を指します。 セクション4.8.3.1onarray初期化子によって、任意の配列initializermayは、ブロックのような構造であるかのように扱われることに注意してください。

4.1ブレース

4.1。1中括弧は、オプションの

中括弧は、ifelsefordowhileステートメントで使用され、thebodyが空であるか、単一の文のみが含まれている場合であっても。

4.1.2空でないブロック:K&Rスタイル

中括弧は、空でないブロックとブロックのような構造のためのKernighanとRitchieスタイル(”Egyptian brackets”)に従います。

  • 開中括弧の前に改行はありません。
  • 開いている中括弧の後に改行します。
  • 閉じ括弧の前に改行します。
  • 閉じ中括弧の後に改行を挿入するのは、その中括弧が文を終了するか、メソッド、コンストラクタ、または名前付きクラスの本体を終了する場合に たとえば、中括弧の後にelseまたはコンマが続く場合、中括弧の後に改行はありません。例:
    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で説明されているように)である可能性があります。 あるいは、amulti-blockステートメント(複数のブロックを直接含むもの:if/elsetry/catch/finally{})。P>

    例:

     // This is acceptable void doNothing() {} // This is equally acceptable void doNothingElse() { }
     // This is not acceptable: No concise empty blocks in a multi-block statement try { doSomething(); } catch (Exception e) {}

    4.2ブロックインデント: +2スペース

    新しいブロックまたはブロックのような構造が開かれるたびに、インデントは二つのスペースだけ増加します。 ブロックが終了すると、インデントは前のインデントレベルに戻ります。 インデントレベルは、ブロック全体のコードとコメントの両方に適用されます。 (セクション4.1.2,空でないブロック:K&Rスタイルの例を参照してください。)

    4.3行ごとに一つの文

    各文の後に改行が続きます。4.4列の制限:100

    Javaコードの列の制限は100文字です。 “文字”とは、任意のUnicodeコードポイントを意味します。以下に記載されている場合を除き、この制限を超える行は、セクション4.5、Line-wrappingで説明されているように、line-wrappedする必要があります。

    各Unicodeコードポイントは、表示幅が大きいかそれ以下であっても、一つの文字としてカウントされます。 たとえば、fullwidth文字を使用する場合は、このルールが厳密に必要とする場所よりも前に行をラップすることを選択できます。

    例外:

    1. 列の制限に従うことができない行(たとえば、Javadocの長いURL、または長いJSNIメソッド参照)。
    2. packageimportステートメント(セクション3.2パッケージステートメントおよび3.3インポートステートメントを参照)。
    3. シェルにカットアンドペーストできるコメント内のコマンドライン。

    4.5Line-wrapping

    用語注:単一の行を合法的に占有する可能性のあるコードを複数の行に分割すると、このアクティビティはline-wrappingと呼ばれます。すべての状況で行を折り返す方法を正確に示す包括的で決定論的な式はありません。

    すべての状況で行を折り返す方法を正確に示す包括的 非常に多くの場合、同じコードを行折り返しする有効な方法がいくつかあります。注:行折り返しの典型的な理由は、列の制限を回避することですが、実際には列の制限内に収まるコードであっても、著者の裁量で行折り返しが行われる可ヒント:メソッドまたはローカル変数を抽出すると、行折り返しを必要とせずに問題が解決する可能性があります。

    4.5.1改行する場所

    行折り返しの主な指示は次のとおりです。 また、

    1. 非代入演算子で行が壊れているとき、改行はシンボルの前に来ます。 (これは、C++やJavaScriptなどの他の言語でGoogleスタイルで使用されているのと同じ方法ではないことに注意してください。
      • ドットセパレータ(.)
      • メソッド参照の二つのコロン(::)
      • 型バインドのアンパサンド(<T extends Foo & Bar>)
      • メソッド参照の二つのコロン(::)
      • 型バウンドのアンパサンド(<T extends Foo & Bar>)
      • catchブロック内のパイプ(catch (FooException | BarException e))。

  • 代入演算子で行が改行されると、通常は記号の後に改行が入りますが、どちらの方法でも許容されます。
    • これは、拡張されたfor(“foreach”)ステートメントの”assignment-operator-like”コロンにも適用されます。
  • メソッド名またはコンストラクタ名は、それに続く開いた括弧(()に添付されたままです。
  • コンマ(,)は、その前のトークンにアタッチされたままになります。
  • ラムダの本体が単一の分割されていない式で構成されている場合、矢印の直後に改行が来ることがあることを除いて、ラムダの矢印の隣に行が破 例:
    MyLambda<String, Long, Object> lambda = (String label, Long value, Object obj) -> { ... };Predicate<String> predicate = str -> longExpressionInvolving(str);
  • 注:行の折り返しの主な目標は、クリアコードを持つことです。

    4.5.2継続行少なくとも+4スペースをインデント

    行折り返しの場合、最初の行(各継続行)の後の各行は、元の行から少なくとも+4インデントされ

    複数の継続行がある場合、インデントはdesiredとして+4を超えて変化させることができます。 一般に、二つの継続行は、構文的に並列な要素を持つ場合にのみ、同じインデントレベルを使用します。

    セクション4.6.3水平整列アドレスについて特定のトークンを前の行に整列させるために可変数のスペースを使用することはお勧めしません。

    4.6空白

    4.6.1垂直空白

    単一の空白行が常に表示されます。

    1. クラスの連続するメンバーまたは初期化子の間: フィールド、コンストラクタ、メソッド、ネストされたクラス、静的初期化子、およびインスタンス初期化子。
      • 例外:二つの連続するフィールドの間に空白行(それらの間に他のコードがない)は省略可能です。 このような空白行は、フィールドの論理グループを作成するために必要に応じて使用されます。
      • 例外:列挙定数間の空白行はセクション4.8.1でカバーされています。
    2. このドキュメントの他のセクション(セクション3、ソースファイル構造、セクション3.3、Importステートメントなど)で要求されているとおりです。

    単一の空白行は、コードを論理的なサブセクションに整理するためのbetweenstatementsなど、読みやすさを向上させる場所にも表示されることがあります。 最初のメンバーまたは初期化子の前、またはクラスの最後のメンバーまたは初期化子の後の空白行は、nordiscouragedでは推奨されません。

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

    4.6.2水平空白

    言語や他のスタイルルールで必要とされる場所を超えて、リテラル、コメント、javadocを除いて、単一のASCIIスペースも次の場所にのみ表示されます。

    1. ifforcatch()から分離します。
    2. 予約語を分離します。elsecatch}{)の前にあります。:
      • @SomeAnnotation({a, b})(スペースは使用されません)
      • String x = {{"foo"}};{{の間にスペースは必要ありません)
    3. バイナリまたは三項演算子 これは、次の”演算子のような”シンボルにも適用されます。
      • 結合型のアンパサンドbound:<T extends Foo & Bar>
      • 複数の例外を処理するcatchブロックのパイプ: catch (FooException | BarException e)
      • 拡張されたfor(“foreach”)ステートメント内のコロン(:for(“foreach”)ステートメント
      • ラムダ式の矢印: (String str) -> str.length()

      しかし、

      • メソッド参照の二つのコロン(::Object::toString
      • ドット区切り(.object.toString()
    4. ,:;)//)の両側にある
    5. 行末コメント。 ここでは、複数のスペースが許可されますが、必須ではありません。
    6. 宣言の型と変数の間:List<String> list
    7. 配列初期化子の両方の中括弧の中にオプション
      • new int {5, 6}new int { 5, 6 }は両方とも有効です
    8. 型注釈と
      の間にnew int { 5, 6 }

    9. 型注釈と
      new int { 5, 6 }

    10. 型注釈と
      new int { 5, 6 }

      new int { 5, 6 }...

      このルールは、行の先頭または末尾に追加のスペースを必要としたり禁止したりすると解釈されることはありません。

      4.6.3水平方向の配置:必須ではありません

      用語の注意: 水平方向の配置は、特定のトークンを前の行の特定の他のトークンのすぐ下に表示することを目的として、コード内に可変数の追加スペースを追加する実この方法は許可されていますが、Googleスタイルでは決して必要とされません。

      それはすでに使用されていた場所でも水平方向の整列を維持する必要があります。

      ここでは、アライメントなしの例であり、アライメントを使用しています。

      private int x; // this is fineprivate Color color; // this tooprivate int x; // permitted, but future editsprivate Color color; // may leave it unaligned

      ヒント:アライメントは読みやすさを助けることができますが、将来のメンテナンスに問題が発生します。 ただ一つの行に触れる必要がある将来の変更を考えてみましょう。 この変更は、以前の書式が変更された可能性があり、それは許可されています。 多くの場合、コーダー(おそらくあなた)に近くの行の空白を調整するように促し、カスケード一連の再構成を可能にします。 その1行の変更には「爆風半径」があります。”これは最悪の場合、無意味なbusyworkになる可能性がありますが、せいぜいバージョン履歴情報を破壊し、レビュアーを遅くし、マージの競合を悪化させます。

      4.7グループ化括弧: 推奨される

      オプションのグループ化括弧は、著者とレビュアーがコードがそれらなしで誤解される可能性がないことに同意した場合にのみ省略され、コードを読むことが容易になったこともありません。 すべての読者がJavaoperatorの優先順位表全体を記憶していると仮定するのは合理的ではありません。

      4.8特定の構成要素

      4.8.1列挙型クラス

      列挙型定数の後に続く各コンマの後には、改行はオプションです。 追加の空白行(通常は1つだけ)も許可されます。 これは一つの可能性です:

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

      メソッドがなく、その定数に関するドキュメントがない列挙型クラスは、配列初期化子であれば、オプションでformattedasすることができます(Section4.8.3.1onarray初期化子を参照)。

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

      列挙型クラスはクラスであるため、クラスの書式設定のための他のすべてのルールが適用されます。

      4.8.2変数宣言

      4.8.2.1宣言ごとに一つの変数

      すべての変数宣言(フィールドまたはローカル)は一つの変数のみを宣言します。int a, b;のような宣言は使用されません。

      例外: 複数の変数宣言は、forループのヘッダーで受け入れられます。

      4.8.2.2必要なときに宣言された

      ローカル変数は、containingblockまたはブロックのような構造の開始時に習慣的に宣言されていません。 代わりに、ローカル変数は、スコープを最小限に抑えるために、最初に使用されたポイントの近くで(理由の範囲内で)宣言されます。 ローカル変数宣言は通常、初期化子を持っているか、宣言の直後に初期化されます。

      4.8.3配列

      4.8.3.1配列初期化子: “block-like”にすることができます

      任意の配列初期化子は、”block-likeeconstruct”であるかのようにオプションでフォーマットすることができます。”たとえば、以下はすべて有効です(exhaustivelistではありません)。

      new int { new int { 0, 1, 2, 3 0,} 1, 2,new int { 3, 0, 1, } 2, 3} new int {0, 1, 2, 3}
      4.8.3.2Cスタイルの配列宣言はありません

      角括弧は、変数ではなく型の一部を形成します。String argsString args

      4.8.4Switch文

      用語注:aswitchブロックの中括弧の内側には、一つ以上の文グループがあります。 各ステートメントグループは、1つ以上のスイッチラベル(case FOO:default:)の後に1つ以上のステートメント(または、最後のステー

      4.8.4.1インデント

      他のブロックと同様に、switchブロックの内容はインデント+2になります。

      スイッチラベルの後、改行があり、ブロックが開かれている場合は、インデントレベルが+2に増加します。 次のスイッチラベルは、ブロックが閉じられたかのように、前のindentationlevelに戻ります。4.8.4.2フォールスルー: コメントされた

      switchブロック内で、各ステートメントグループが突然終了するか(breakcontinuereturnまたは例外がスローされます)、または次のステートメントグループに実行が継続されるか、継続される可能性があることを示すコメントでマークされています。 フォールスルーのアイデアを伝えるAnycommentで十分です(通常は// fall through)。 この特別なコメントは、switchブロックの最後のステートメントグループでは必要ありません。 例:

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

      case 1:の後にコメントは必要ないことに注意してください。

      4.8.4.3defaultケースが存在します

      各switch文には、コードが含まれていなくても、defaultstatementgroupが含まれています。

      例外:enum型のswitch文は、その型のすべての可能な値をカバーする明示的なケースが含まれている場合、default文グループを省略するこ これにより、Ideやその他のstaticanalysisツールは、いずれかのケースが見逃された場合に警告を発行することができます。

      4.8.5注釈

      クラス、メソッド、またはコンストラクタに適用される注釈は、documentationブロックの直後に表示され、各注釈は独自の行(つまり、annotationper行)にリストさ これらの改行は行折り返し(Section4.5,Line-wrapping)を構成しないため、インデントレベルは増加しません。 例:

      @Override@Nullablepublic String getNameIfPresent() { ... }

      例外: たとえば、

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

      フィールドに適用される注釈もドキュメントブロックの直後に表示されますが、この場合、複数の注釈(パラメータ化されている可能性があります)が同じ行に一覧表示されることがあります。

      @Partial @Mock DataLoader loader;

      パラメータの注釈の書式設定に関する特別な規則はありません。ローカル変数、または型。

      このセクションでは、実装のコメントについて説明します。 Javadocは、セクション7、Javadocで別々に対処されています。

      任意の改行の前に任意の空白を付け、その後に実装コメントを付けることができます。このようなコメントは、行を空白ではなくレンダリングします。

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

      ブロックコメントは、周囲のコードと同じレベルでインデントされます。 それらは、/* ... */// .../* ... */**で始まる必要があります。

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

      コメントは、アスタリスクやその他の文字で描かれたボックスで囲まれていません。ヒント:複数行のコメントを書くときは、必要に応じて自動コードフォーマッタが行を引き裂きたい場合は、/* ... */// ...スタイルのコメントブロックで行を再ラップしません。クラス修飾子とメンバー修飾子は、存在する場合、Java言語仕様で推奨されている順序で表示されます。

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

      4.8。8数値リテラル

      longLサフィックス、neverlowercaseを使用します(数字13000000000l3000000000Lです。

      5命名

      5.1すべての識別子に共通するルール

      識別子はASCII文字と数字のみを使用し、以下に示す少数のケースではアンダースコアを使用 したがって、各有効な識別子名は正規表現\w+と一致します。

      In Google Style, special prefixes or suffixes are not used. For example, thesenames are not Google Style: name_mNames_name and kName.

      5.2 Rules by identifier type

      5.2.1 Package names

      Package names are all lowercase, with consecutive words simply concatenated together (nounderscores). For example, com.example.deepspace, notcom.example.deepSpace orcom.example.deep_space.

      5.2.2 Class names

      Class names are written in UpperCamelCase.クラス名は通常、名詞または名詞句です。

      クラス名は通常名詞または名詞句です。

      たとえば、CharacterImmutableListListReadable)でもよい。

      注釈型の名前付けには、特定の規則や確立された規則はありません。

      テストクラスの名前は、テストするクラスの名前で始まり、endingwithTestHashTestHashIntegrationTestです。

      5.2.3メソッド名

      メソッド名はlowerCamelCaseで記述されます。

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

      アンダースコアは、JUnitテストメソッド名に表示され、名前の論理コンポーネントを分離し、各コンポーネントをlowerCamelCaseで記述することができます。典型的なパターンは、<methodUnderTest>_<state>pop_emptyStackです。 正しいものはありませんテスト方法に名前を付ける方法。5.2.

      4定数名

      定数名はCONSTANT_CASEすべてのuppercaselettersを使用し、各単語は単一のアンダースコアで次の単語から分離されています。 しかし、正確には、aconstantは何ですか?

      定数は、内容が深く不変であり、メソッドがnodetable副作用を持つ静的な最終フィールドです。 これには、プリミティブ、文字列、不変型、および不変型のimmutablecollectionsが含まれます。 インスタンスの監視可能な状態のいずれかが変更される可能性がある場合、それは一致しません。 単にオブジェクトを変更しないことを意図するだけでは十分ではありません。 例:p>

      // Constantsstatic 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 immutablestatic final SomeMutableType EMPTY_ARRAY = {};enum SomeEnum { ENUM_CONSTANT }// Not constantsstatic 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に書き込まれます。これらの名前は、通常、名詞または名詞句です。

      これらの名前は、通常、名詞または名詞句です。 たとえば、computedValuesindexです。

      5.2.6パラメータ名

      パラメータ名はlowerCamelCaseで記述されます。

      パブリックメソッドでは、1文字のパラメータ名は避けるべきです。

      5.2.7ローカル変数名

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

      finalおよびimmutableの場合でも、ローカル変数は定数とはみなされず、定数としてスタイル設定されるべきではありません。

      5.2.8型変数名

      各型変数は、次のいずれかのスタイルで名前が付けられます。

      • 単一の大文字、必要に応じて単一の数字(ETXEEEEEET2

      )

    11. クラスに使用される形式の名前(セクション5.2.2,クラス名を参照)、その後に大文字TRequestTFooBarT)。
    12. 5.3Camel case:defined

      頭字語や”Ipv6″や”iOS”のような珍しい構成体が存在する場合など、英語のフレーズをcamel caseに変換するための合理的な方法が複数あります。 予測可能性を向上させるために、Google Styleは次の(ほぼ)決定論的なスキームを指定します。

      名前の散文形式で始まります。

      1. フレーズをプレーンなASCIIに変換し、アポストロフィを削除します。 たとえば、”Müller’s algorithm”は”Muellers algorithm”になる可能性があります。
      2. この結果を単語に分割し、スペースと残りの句読点(通常はハイフン)で分割します。
        • 推奨:いずれかの単語が既に一般的な使用法で従来のキャメルケースの外観を持っている場合は、これをその構成部分に分割します(例えば、”AdWords”は”ad words”にな “IOS”のような単語は実際にはcamelの場合ではないことに注意してください。
      3. すべて(頭字語を含む)を小文字にし、
        • の最初の文字のみを大文字にします。.. 各単語は、大文字小文字、または
        • を生成します。.. 最初の単語を除く各単語は、低いキャメルケースを生成するために
      4. 最後に、単一の識別子にすべての単語を結合します。

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

      Prose form Correct Incorrect
      “XML HTTP request” XmlHttpRequest XMLHTTPRequest
      “new customer ID” newCustomerId newCustomerID
      “inner stopwatch” innerStopwatch innerStopWatch
      “supports IPv6 on iOS?” supportsIpv6OnIos supportsIPv6OnIOS
      “YouTube importer” YouTubeImporter
      YoutubeImporter*

      *Acceptable, but not recommended.

      Note: Some words are ambiguously hyphenated in the Englishlanguage: for example “nonempty” and “non-empty” are both correct, so the method namescheckNonempty andcheckNonEmpty are likewise both correct.

      6 Programming Practices

      6.1 @Override: 常に使用される

      メソッドは、それが合法であるときに@Override注釈でマークされています。 これには、スーパークラスメソッドをオーバーライドするクラスメソッド、インターフェイスメソッドを実装するクラスmethodimplementing、およびsuperinterfacemethodをrespecifyingインターフェースメソ親メソッドが@Deprecated@Overrideは省略される可能性があります。

      6.2キャッチされた例外:無視されない

      以下に記載されていることを除いて、caughtexceptionに応答して何もしないことは非常にまれです。 (典型的な応答は、それをログに記録するか、「不可能」と見なされる場合は、それを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);

      例外:テストでは、キャッチされた例外が、その名前がexpectedで始まる場合、コメントなしで無視されることがあります。 Thefollowingは、テスト対象のコードが期待される型のanexceptionをスローすることを保証するための非常に一般的なイディオムであるため、ここではコメントは不要です。

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

      6.3静的メンバー:classを使用して修飾

      静的クラスメンバーへの参照を修飾する必要がある場合、そのクラスの型の参照や式ではなく、そのクラスの名前で修飾されます。p>

      Foo aFoo = ...;Foo.aStaticMethod(); // goodaFoo.aStaticMethod(); // badsomethingThatYieldsAFoo().aStaticMethod(); // very bad

      6.4ファイナライザ:使用されていません

      Object.finalizeをオーバーライドすることは非常にまれです。ヒント:それをしないでください。

      絶対に必要な場合は、最初にEffective Javaの項目7「Finalizersを避ける」を非常に慎重に読んで理解してから、それをしないでください。

      7Javadoc

      7.1フォーマット

      7.1.Javadocブロックの基本的な書式設定は、次の例のようになります。

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

      。.. または、この単一行の例では:

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

      基本的な形式は常に許容されます。 単一行形式は、Javadocブロックの全体(コメント-マーカーを含む)が単一行に収まる場合に置換できます。 これは、@returnなどのブロックタグがない場合にのみ適用されることに注意してください。7.1.

      2段落

      一つの空白行、すなわち、整列された先頭のアスタリスクのみを含む行(*)—段落の間、ブロックタグifpresentのグループの前に表示されます。 最初の段落は<p>最初の単語の直前にあり、後にスペースはありません。

      7.1.3ブロックタグ

      使用される標準の”ブロックタグ”のいずれかが、@param@return@throws@deprecated@の位置から四つ(またはそれ以上)のスペースをインデントします。

      7.2要約フラグメント

      各Javadocブロックは簡単な要約フラグメントで始まります。 Thisfragmentは非常に重要です:クラスやメソッドインデックスなどの特定のコンテキストに表示されるテキストの唯一の部分です。これは断片です—名詞句または動詞句であり、完全な文ではありません。

      これは断片です。

      完全な文ではありません。 それはA {@code Foo} is a...This method returns...Save the record.のような完全な命令文を形成することもありません。 しかし、断片は大文字であり、それが完全な文であるかのように構成されています。ヒント:よくある間違いは、単純なJavadocを/** @return the customer ID *//** Returns the customer ID. */に変更する必要があります。

      7.3Javadocが使用されている場合

      少なくとも、Javadocはすべてのpublicpublicprotectedセクション7.3.4,不要なJavadocで説明されているように、追加のJavadocコンテンツも存在する可能性があります。

      追加のJavadocコンテンツも存在する可能性があJavadocは、getFooのような”単純で明白な”メソッドではオプションですが、本当に本当に言う価値はありませんが、”fooを返します”。

      重要なこと

      : 一般的な読者が知る必要があるかもしれない関連情報を正当化するためにこの例外を引用することは適切ではありません。 たとえば、メソッド名getCanonicalName/** Returns the canonical name. */のみと言うという理論的根拠を持っています)。

      7.3.2例外:overrides

      javadocは、スーパータイプ-メソッドをオーバーライドするメソッドに常に存在するとは限りません。

      7.3.4必要でないJavadoc

      他のクラスおよびメンバーは、必要または必要に応じてJavadocを持っています。

    Related Posts

    コメントを残す

    メールアドレスが公開されることはありません。 * が付いている欄は必須項目です