• 源檔案基礎
• 源檔案結構
• 格式
• 命名約定
• 程式設計實踐
• Javadoc

---

這份檔案是Google Java程式設計風格規範的完整定義。當且僅當一個Java源檔案符合此檔案中的規則， 我們才認為它符合Google的Java程式設計風格。

與其它的程式設計風格指南一樣，這裡所討論的不僅僅是編碼格式美不美觀的問題， 同時也討論一些約定及編碼標準。然而，這份檔案主要側重於我們所普遍遵循的規則， 對於那些不是明確強制要求的，我們儘量避擴音供意見。

1.1 術語說明

在本檔案中，除非另有說明：

1. 術語class可表示一個普通類，列舉類，介面或是annotation型別( @interface)
2. 術語comment只用來指代實現的註釋(implementation comments)，我們不使用“documentation comments”一詞，而是用Javadoc。

其他的術語說明會偶爾在後面的檔案出現。

1.2 指南說明

本檔案中的示例程式碼並不作為規範。也就是說，雖然示例程式碼是遵循Google程式設計風格，但並不意味著這是展現這些程式碼的唯一方式。示例中的格式選擇不應該被強制定為規則。

源檔案基礎

2.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, “, ‘及)，我們使用它的轉義序列，而不是相應的八進位制(比如 \012)或Unicode(比如 \u000a)轉義。

2.3.3 非ASCII字元

對於剩餘的非ASCII字元，是使用實際的Unicode字元(比如∞)，還是使用等價的Unicode轉義符(比如\u221e)，取決於哪個能讓程式碼更易於閱讀和理解。

Tip: 在使用Unicode轉義符或是一些實際的Unicode字元時，建議做些註釋給出解釋，這有助於別人閱讀和理解。

例如：

String unitAbbrev = "μs";                                 | 贊，即使沒有註釋也非常清晰String unitAbbrev = "\u03bcs"; // "μs"                    | 允許，但沒有理由要這樣做String unitAbbrev = "\u03bcs"; // Greek letter mu, "s"    | 允許，但這樣做顯得笨拙還容易出錯String unitAbbrev = "\u03bcs";                            | 很糟，讀者根本看不出這是什麼return '\ufeff' + content; // byte order mark             | Good，對於非列印字元，使用轉義，併在必要時寫上註釋

Tip: 永遠不要由於害怕某些程式可能無法正確處理非ASCII字元而讓你的程式碼可讀性變差。當程式無法正確處理非ASCII字元時，它自然無法正確執行， 你就會去fix這些問題的了。(言下之意就是大膽去用非ASCII字元，如果真的有需要的話)

源檔案結構

一個源檔案包含(按順序地)：

1. 許可證或版權資訊(如有需要)
2. package陳述句
3. import陳述句
4. 一個頂級類(只有一個)

以上每個部分之間用一個空行隔開。

3.1 許可證或版權資訊

如果一個檔案包含許可證或版權資訊，那麼它應當被放在檔案最前面。

3.2 package陳述句

package陳述句不換行，列限制(4.4節)並不適用於package陳述句。(即package陳述句寫在一行裡)

3.3 import陳述句

3.3.1 import不要使用萬用字元

即，不要出現類似這樣的import陳述句：importjava.util.*;

3.3.2 不要換行

import陳述句不換行，列限制(4.4節)並不適用於import陳述句。(每個import陳述句獨立成行)

3.3.3 順序和間距

import陳述句可分為以下幾組，按照這個順序，每組由一個空行分隔：

1. 所有的靜態匯入獨立成組
2. com.google imports(僅當這個源檔案是在 com.google包下)
3. 第三方的包。每個頂級包為一組，字典序。例如：android, com, junit, org, sun
4. java imports
5. javax imports

組內不空行，按字典序排列。

3.4 類宣告

3.4.1 只有一個頂級類宣告

每個頂級類都在一個與它同名的源檔案中(當然，還包含 .java字尾)。

例外：package-info.java，該檔案中可沒有 package-info類。

3.4.2 類成員順序

類的成員順序對易學性有很大的影響，但這也不存在唯一的通用法則。不同的類對成員的排序可能是不同的。最重要的一點，每個類應該以某種邏輯去排序它的成員，維護者應該要能解釋這種排序邏輯。比如， 新的方法不能總是習慣性地新增到類的結尾，因為這樣就是按時間順序而非某種邏輯來排序的。

3.4.2.1 多載：永不分離

當一個類有多個建構式，或是多個同名方法，這些函式/方法應該按順序出現在一起，中間不要放進其它函式/方法。

格式

術語說明：塊狀結構(block-like construct)指的是一個類，方法或建構式的主體。需要註意的是，陣列初始化中的初始值可被選擇性地視為塊狀結構(4.8.3.1節)。

4.1 大括號

4.1.1 使用大括號(即使是可選的)

大括號與 if,else,for,do,while陳述句一起使用，即使只有一條陳述句(或是空)，也應該把大括號寫上。

4.1.2 非空塊：K & R 風格

對於非空塊和塊狀結構，大括號遵循Kernighan和Ritchie風格 (Egyptian brackets):

• 左大括號前不換行
• 左大括號後換行
• 右大括號前換行
• 如果右大括號是一個陳述句、函式體或類的終止，則右大括號後換行; 否則不換行。例如，如果右大括號後面是else或逗號，則不換行。

示例：

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

4.8.1節給出了enum類的一些例外。

4.1.3 空塊：可以用簡潔版本

一個空的塊狀結構裡什麼也不包含，大括號可以簡潔地寫成 {}，不需要換行。例外：如果它是一個多塊陳述句的一部分(if/else 或 try/catch/finally) ，即使大括號內沒內容，右大括號也要換行。

示例：

void doNothing() {}

4.2 塊縮排：2個空格

每當開始一個新的塊，縮排增加2個空格，當塊結束時，縮排傳回先前的縮排級別。縮排級別適用於程式碼和註釋。(見4.1.2節中的程式碼示例)

4.3 一行一個陳述句

每個陳述句後要換行。

4.4 列限制：80或100

一個專案可以選擇一行80個字元或100個字元的列限制，除了下述例外，任何一行如果超過這個字元數限制，必須自動換行。

例外：

1. 不可能滿足列限制的行(例如，Javadoc中的一個長URL，或是一個長的JSNI方法參考)。
2. package和 import陳述句(見3.2節和3.3節)。
3. 註釋中那些可能被剪下並貼上到shell中的命令列。

4.5 自動換行

術語說明：一般情況下，一行長程式碼為了避免超出列限制(80或100個字元)而被分為多行，我們稱之為自動換行(line-wrapping)。

我們並沒有全面，確定性的準則來決定在每一種情況下如何自動換行。很多時候，對於同一段程式碼會有好幾種有效的自動換行方式。

Tip: 提取方法或區域性變數可以在不換行的情況下解決程式碼過長的問題(是合理縮短命名長度吧)

4.5.1 從哪裡斷開

自動換行的基本準則是：更傾向於在更高的語法級別處斷開。

1. 如果在 非賦值運運算元處斷開，那麼在該符號前斷開(比如+，它將位於下一行)。註意：這一點與Google其它語言的程式設計風格不同(如C++和JavaScript)。這條規則也適用於以下“類運運算元”符號：點分隔符(.)，型別界限中的&（ )，catch塊中的管道符號( catch(FooException|BarExceptione)
2. 如果在 賦值運運算元處斷開，通常的做法是在該符號後斷開(比如=，它與前面的內容留在同一行)。這條規則也適用於 foreach陳述句中的分號。
3. 方法名或建構式名與左括號留在同一行。
4. 逗號(,)與其前面的內容留在同一行。

4.5.2 自動換行時縮排至少+4個空格

自動換行時，第一行後的每一行至少比第一行多縮排4個空格(註意：製表符不用於縮排。見2.3.1節)。

當存在連續自動換行時，縮排可能會多縮排不只4個空格(語法元素存在多級時)。一般而言，兩個連續行使用相同的縮排當且僅當它們開始於同級語法元素。

第4.6.3水平對齊一節中指出，不鼓勵使用可變數目的空格來對齊前面行的符號。

4.6 空白

4.6.1 垂直空白

以下情況需要使用一個空行：

1. 類內連續的成員之間：欄位，建構式，方法，巢狀類，靜態初始化塊，實體初始化塊。

2. – 例外：兩個連續欄位之間的空行是可選的，用於欄位的空行主要用來對欄位進行邏輯分組。

3. 在函式體內，陳述句的邏輯分組間使用空行。

4. 類內的第一個成員前或最後一個成員後的空行是可選的(既不鼓勵也不反對這樣做，視個人喜好而定)。

5. 要滿足本檔案中其他節的空行要求(比如3.3節：import陳述句)

多個連續的空行是允許的，但沒有必要這樣做(我們也不鼓勵這樣做)。

4.6.2 水平空白

除了語言需求和其它規則，並且除了文字，註釋和Javadoc用到單個空格，單個ASCII空格也出現在以下幾個地方：

1. 分隔任何保留字與緊隨其後的左括號( ()(如 if,forcatch等)。

2. 分隔任何保留字與其前面的右大括號( })(如 else,catch)。

3. 在任何左大括號前( {)，兩個例外：

4. – @SomeAnnotation({a,b})(不使用空格)。

• String[][]x=foo;(大括號間沒有空格，見下麵的Note)。

1. 在任何二元或三元運運算元的兩側。這也適用於以下“類運運算元”符號：

2. – 型別界限中的&( )。

• catch塊中的管道符號( catch(FooException|BarExceptione)。
• foreach陳述句中的分號。

1. 在 ,:;及右括號( ))後

2. 如果在一條陳述句後做註釋，則雙斜槓(//)兩邊都要空格。這裡可以允許多個空格，但沒有必要。

3. 型別和變數之間：List list。

4. 陣列初始化中，大括號內的空格是可選的，即 newint[]{5,6}和 newint[]{5,6}都是可以的。

Note：這個規則並不要求或禁止一行的開關或結尾需要額外的空格，只對內部空格做要求。

4.6.3 水平對齊：不做要求

術語說明：水平對齊指的是透過增加可變數量的空格來使某一行的字元與上一行的相應字元對齊。

這是允許的(而且在不少地方可以看到這樣的程式碼)，但Google程式設計風格對此不做要求。即使對於已經使用水平對齊的程式碼，我們也不需要去保持這種風格。

以下示例先展示未對齊的程式碼，然後是對齊的程式碼：

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

Tip：對齊可增加程式碼可讀性，但它為日後的維護帶來問題。考慮未來某個時候，我們需要修改一堆對齊的程式碼中的一行。這可能導致原本很漂亮的對齊程式碼變得錯位。很可能它會提示你調整週圍程式碼的空白來使這一堆程式碼重新水平對齊(比如程式員想保持這種水平對齊的風格)， 這就會讓你做許多的無用功，增加了reviewer的工作並且可能導致更多的合併衝突。

4.7 用小括號來限定組：推薦

除非作者和reviewer都認為去掉小括號也不會使程式碼被誤解，或是去掉小括號能讓程式碼更易於閱讀，否則我們不應該去掉小括號。我們沒有理由假設讀者能記住整個Java運運算元優先順序表。

4.8 具體結構

4.8.1 列舉類

列舉常量間用逗號隔開，換行可選。

沒有方法和檔案的列舉類可寫成陣列初始化的格式：

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

由於列舉類也是一個類，因此所有適用於其它類的格式規則也適用於列舉類。

4.8.2 變數宣告

4.8.2.1 每次只宣告一個變數

不要使用組合宣告，比如 inta,b;。

4.8.2.2 需要時才宣告，並儘快進行初始化

不要在一個程式碼塊的開頭把區域性變數一次性都宣告了(這是c語言的做法)，而是在第一次需要使用它時才宣告。區域性變數在宣告時最好就進行初始化，或者宣告後儘快進行初始化。

4.8.3 陣列

4.8.3.1 陣列初始化：可寫成塊狀結構

陣列初始化可以寫成塊狀結構，比如，下麵的寫法都是OK的：

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.2 非C風格的陣列宣告

中括號是型別的一部分：String[]args， 而非 Stringargs[]。

4.8.4 switch陳述句

術語說明：switch塊的大括號內是一個或多個陳述句組。每個陳述句組包含一個或多個switch標簽( caseFOO:或 default:)，後面跟著一條或多條陳述句。

4.8.4.1 縮排

與其它塊狀結構一致，switch塊中的內容縮排為2個空格。

每個switch標簽後新起一行，再縮排2個空格，寫下一條或多條陳述句。

4.8.4.2 Fall-through：註釋

在一個switch塊內，每個陳述句組要麼透過 break,continue,return或丟擲異常來終止，要麼透過一條註釋來說明程式將繼續執行到下一個陳述句組， 任何能表達這個意思的註釋都是OK的(典型的是用 // fall through)。這個特殊的註釋並不需要在最後一個陳述句組(一般是 default)中出現。示例：

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

4.8.4.3 default的情況要寫出來

每個switch陳述句都包含一個 default陳述句組，即使它什麼程式碼也不包含。

4.8.5 註解(Annotations)

註解緊跟在檔案塊後面，應用於類、方法和建構式，一個註解獨佔一行。這些換行不屬於自動換行(第4.5節，自動換行)，因此縮排級別不變。例如：

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

例外：單個的註解可以和簽名的第一行出現在同一行。例如：

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

應用於欄位的註解緊隨檔案塊出現，應用於欄位的多個註解允許與欄位出現在同一行。例如：

@Partial @Mock DataLoader loader;

引數和區域性變數註解沒有特定規則。

4.8.6 註釋

4.8.6.1 塊註釋風格

塊註釋與其周圍的程式碼在同一縮排級別。它們可以是 /* ... */風格，也可以是 // ...風格。對於多行的 /* ... */註釋，後續行必須從 *開始， 並且與前一行的 *對齊。以下示例註釋都是OK的。

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

註釋不要封閉在由星號或其它字元繪製的框架裡。

Tip：在寫多行註釋時，如果你希望在必要時能重新換行(即註釋像段落風格一樣)，那麼使用 /* ... */。

4.8.7 Modifiers

類和成員的modifiers如果存在，則按Java語言規範中推薦的順序出現。

public protected private abstract static final transient volatile synchronized native strictfp

命名約定

5.1 對所有識別符號都通用的規則

識別符號只能使用ASCII字母和數字，因此每個有效的識別符號名稱都能匹配正則運算式 \w+。

在Google其它程式語言風格中使用的特殊字首或字尾，如 name_, mName, s_name和 kName，在Java程式設計風格中都不再使用。

5.2 識別符號型別的規則

5.2.1 包名

包名全部小寫，連續的單詞只是簡單地連線起來，不使用下劃線。

5.2.2 類名

類名都以 UpperCamelCase風格編寫。

類名通常是名詞或名詞短語，介面名稱有時可能是形容詞或形容詞短語。現在還沒有特定的規則或行之有效的約定來命名註解型別。

測試類的命名以它要測試的類的名稱開始，以 Test結束。例如， HashTest或 HashIntegrationTest。

5.2.3 方法名

方法名都以 lowerCamelCase風格編寫。

方法名通常是動詞或動詞短語。

下劃線可能出現在JUnit測試方法名稱中用以分隔名稱的邏輯元件。一個典型的樣式是：test_，例如 testPop_emptyStack。並不存在唯一正確的方式來命名測試方法。

5.2.4 常量名

常量名命名樣式為 CONSTANT_CASE，全部字母大寫，用下劃線分隔單詞。那，到底什麼算是一個常量？

每個常量都是一個靜態final欄位，但不是所有靜態final欄位都是常量。在決定一個欄位是否是一個常量時， 考慮它是否真的感覺像是一個常量。例如，如果任何一個該實體的觀測狀態是可變的，則它幾乎肯定不會是一個常量。只是永遠不 打算改變物件一般是不夠的，它要真的一直不變才能將它示為常量。

// Constantsstatic final int NUMBER = 5;static final ImmutableList NAMES = ImmutableList.of("Ed", "Ann");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 mutableCollection = new HashSet();static final ImmutableSet mutableElements = ImmutableSet.of(mutable);static final Logger logger = Logger.getLogger(MyClass.getName());static final String[] nonEmptyArray = {"these", "can", "change"};

這些名字通常是名詞或名詞短語。

5.2.5 非常量欄位名

非常量欄位名以 lowerCamelCase風格編寫。

這些名字通常是名詞或名詞短語。

5.2.6 引數名

引數名以 lowerCamelCase風格編寫。

引數應該避免用單個字元命名。

5.2.7 區域性變數名

區域性變數名以 lowerCamelCase風格編寫，比起其它型別的名稱，區域性變數名可以有更為寬鬆的縮寫。

雖然縮寫更寬鬆，但還是要避免用單字元進行命名，除了臨時變數和迴圈變數。

即使區域性變數是final和不可改變的，也不應該把它示為常量，自然也不能用常量的規則去命名它。

5.2.8 型別變數名

型別變數可用以下兩種風格之一進行命名：

• 單個的大寫字母，後面可以跟一個數字(如：E, T, X, T2)。
• 以類命名方式(5.2.2節)，後面加個大寫的T(如：RequestT, FooBarT)。

5.3 駝峰式命名法(CamelCase)

駝峰式命名法分大駝峰式命名法( UpperCamelCase)和小駝峰式命名法( lowerCamelCase)。有時，我們有不只一種合理的方式將一個英語片語轉換成駝峰形式，如縮略語或不尋常的結構(例如”IPv6”或”iOS”)。Google指定了以下的轉換方案。

名字從 散文形式(prose form)開始:

1. 把短語轉換為純ASCII碼，並且移除任何單引號。例如：”Müller’s algorithm”將變成”Muellers algorithm”。

2. 把這個結果切分成單詞，在空格或其它標點符號(通常是連字元)處分割開。

3. – 推薦：如果某個單詞已經有了常用的駝峰表示形式，按它的組成將它分割開(如”AdWords”將分割成”ad words”)。需要註意的是”iOS”並不是一個真正的駝峰表示形式，因此該推薦對它並不適用。

4. 現在將所有字母都小寫(包括縮寫)，然後將單詞的第一個字母大寫：

5. – 每個單詞的第一個字母都大寫，來得到大駝峰式命名。

• 除了第一個單詞，每個單詞的第一個字母都大寫，來得到小駝峰式命名。

1. 最後將所有的單詞連線起來得到一個識別符號。

示例：

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*

加星號處表示可以，但不推薦。

Note：在英語中，某些帶有連字元的單詞形式不唯一。例如：”nonempty”和”non-empty”都是正確的，因此方法名 checkNonempty和 checkNonEmpty也都是正確的。

程式設計實踐

6.1 @Override：能用則用

只要是合法的，就把 @Override註解給用上。

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);

例外：在測試中，如果一個捕獲的異常被命名為 expected，則它可以被不加註釋地忽略。下麵是一種非常常見的情形，用以確保所測試的方法會丟擲一個期望中的異常， 因此在這裡就沒有必要加註釋。

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

6.3 靜態成員：使用類進行呼叫

使用類名呼叫靜態的類成員，而不是具體某個物件或運算式。

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

6.4 Finalizers: 禁用

極少會去重寫 Object.finalize。

Tip：不要使用finalize。如果你非要使用它，請先仔細閱讀和理解Effective Java 第7條款：“Avoid Finalizers”，然後不要使用它。

Javadoc

7.1 格式

7.1.1 一般形式

Javadoc塊的基本格式如下所示：

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

或者是以下單行形式：

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

基本格式總是OK的。當整個Javadoc塊能容納於一行時(且沒有Javadoc標記@XXX)，可以使用單行形式。

7.1.2 段落

空行(即，只包含最左側星號的行)會出現在段落之間和Javadoc標記(@XXX)之前(如果有的話)。除了第一個段落，每個段落第一個單詞前都有標簽

 

，並且它和第一個單詞間沒有空格。

7.1.3 Javadoc標記

標準的Javadoc標記按以下順序出現：@param, @return, @throws, @deprecated, 前面這4種標記如果出現，描述都不能為空。當描述無法在一行中容納，連續行需要至少再縮排4個空格。

7.2 摘要片段

每個類或成員的Javadoc以一個簡短的摘要片段開始。這個片段是非常重要的，在某些情況下，它是唯一齣現的文字，比如在類和方法索引中。

這隻是一個小片段，可以是一個名詞短語或動詞短語，但不是一個完整的句子。它不會以 A{@codeFoo}isa...或 Thismethod returns...開頭, 它也不會是一個完整的祈使句，如 Savethe record...。然而，由於開頭大寫及被加了標點，它看起來就像是個完整的句子。

Tip：一個常見的錯誤是把簡單的Javadoc寫成 /** @return the customer ID */，這是不正確的。它應該寫成 /** Returns the customer ID. */。

7.3 哪裡需要使用Javadoc

至少在每個public類及它的每個public和protected成員處使用Javadoc，以下是一些例外：

7.3.1 例外：不言自明的方法

對於簡單明顯的方法如 getFoo，Javadoc是可選的(即，是可以不寫的)。這種情況下除了寫“Returns the foo”，確實也沒有什麼值得寫了。

單元測試類中的測試方法可能是不言自明的最常見例子了，我們通常可以從這些方法的描述性命名中知道它是乾什麼的，因此不需要額外的檔案說明。

Tip：如果有一些相關資訊是需要讀者瞭解的，那麼以上的例外不應作為忽視這些資訊的理由。例如，對於方法名 getCanonicalName， 就不應該忽視檔案說明，因為讀者很可能不知道詞語 canonical name指的是什麼。

7.3.2 例外：重寫

如果一個方法重寫了超類中的方法，那麼Javadoc並非必需的。

7.3.3 可選的Javadoc

對於包外不可見的類和方法，如有需要，也是要使用Javadoc的。如果一個註釋是用來定義一個類，方法，欄位的整體目的或行為， 那麼這個註釋應該寫成Javadoc，這樣更統一更友好。