重要的是，每個class都要按照一定的邏輯規律排序。當被問及時，能夠解釋清楚為什么這樣排序。例如，新增加的成員方法，不是簡單地放在class代碼最后面，按日期排序不是按邏輯排序。
術語說明：塊狀結構（block-like construct）指類、成員函數和構造函數的實現部分（花括號中間部分）。注意，在后面的4.8.3.1節中講到數組初始化，所有的數組初始化都可以被認為是一個塊狀結構（非強制）。
一些例外的情況，將在4.8.1節講枚舉類型的時候講到。
4.1.3 空語句塊：使代碼更簡潔
一個空的語句塊，可以在左花括號之后直接接右花括號，中間不需要空格或換行。但是當一個由幾個語句塊聯合組成的語句塊時，則需要換行。（例如：if/else-if/else try/catch/finally）.
例子：
4.2 語句塊的縮進：2空格
每當一個新的語句塊產生，縮進就增加兩個空格。當這個語句塊結束時，縮進恢復到上一層級的縮進格數?？s進要求對整個語句塊中的代碼和注釋都適用。（例子可參考之前4.1.2節中的例子）。
4.3 一行最多只有一句代碼
每句代碼的結束都需要換行。
4.4 行長度限制：80或100
不同的項目可以選擇采用80個字符或者100個字符作為限制。除了以下幾個特殊情況外，其他代碼內容都需要遵守這個長度限制。這在4.5節會有詳細解釋。
例外：
a、按照行長度限制，無法實現地方（例如：javadoc中超長的URL地址， 或者一個超長的JSNI方法的引用）；
b、package和import語句不受長度限制。（見3.2、3.3節）；
c、注釋中的命令行指令行，將被直接復制到shell中執行的。
4.5 長行斷行
術語說明：當一行代碼按照其他規范都合法，只是為了避免超出行長度限制而換行時，稱為長行斷行。
長行斷行，沒有一個適合所有場景的全面、確定的規范。但很多相同的情況，我們經常使用一些行之有效的斷行方法。
注意：將長行封裝為函數，或者使用局部變量的方法，也可以解決一些超出行長度限制的情況。并非一定要斷行。
4.5.1 在何處斷行
斷行的主要原則是：選擇在更高一級的語法邏輯的地方斷行。其他一些原則如下：
a、當一個非賦值運算的語句斷行時，在運算符號之前斷行。（這與Google的C++規范和JavaScrip規范等其他規范不同）。
b、當一個賦值運算語句斷行時，一般在賦值符號之后斷行。但是也可以在之前斷行。
c、在調用函數或者構造函數需要斷行時，與函數名相連的左括號要在一行。也就是在左括號之后斷行。
d、逗號斷行時，要和逗號隔開的前面的語句斷行。也就是在逗號之后斷行。
4.5.2 斷行的縮進：至少4個字符
當斷行之后，在第一行之后的行，我們叫做延續行。每一個延續行在第一行的基礎上至少縮進四個字符。
當原行之后有多個延續行的情況，縮進可以大于4個字符。如果多個延續行之間由同樣的語法元素斷行，它們可以采用相同的縮進。
4.6.3節介紹水平對齊中，解決了使用多個空格與之前行縮進對齊的問題。
4.6 空白空間
4.6.1 垂直空白
單行空行在以下情況使用：
a、類成員間需要空行隔開：例如成員變量、構造函數、成員函數、內部類、靜態初始化語句塊（static initializers）、實例初始化語句塊（instance initializers）。
例外：成員變量之間的空白行不是必需的。一般多個成員變量中間的空行，是為了對成員變量做邏輯上的分組。
b、在函數內部，根據代碼邏輯分組的需要，設置空白行作為間隔。
c、類的第一個成員之前，或者最后一個成員結束之后，用空行間隔。（可選）
d、本文檔中其他部分介紹的需要空行的情況。（例如 3.3節中的import語句）
單空行時使用多行空行是允許的，但是不要求也不鼓勵。
4.6.2 水平空白
除了語法、其他規則、詞語分隔、注釋和javadoc外，水平的ASCII空格只在以下情況出現：
a、所有保留的關鍵字與緊接它之后的位于同一行的左括號之間需要用空格隔開。（例如if、for、catch）
b、所有保留的關鍵字與在它之前的右花括號之間需要空格隔開。（例如else、catch）
c、在左花括號之前都需要空格隔開。只有兩種例外：
@SomeAnnotation({a, b})
String[][] x = {{"foo"}};
d、所有的二元運算符和三元運算符的兩邊，都需要空格隔開。
e、逗號、冒號、分號和右括號之后，需要空格隔開。
f、// 雙斜線開始一行注釋時。雙斜線兩邊都應該用空格隔開。并且可使用多個空格，但是不做強制要求。
g、變量聲明時，變量類型和變量名之間需要用空格隔開。
h、初始化一個數組時，花括號之間可以用空格隔開，也可以不使用。（例如：new int[] {5, 6} 和 new int[] { 5, 6 } 都可以）
注意：這一原則不影響一行開始或者結束時的空格。只針對行內部字符之間的隔開。
4.6.3 水平對齊：不做強制要求
術語說明：水平對齊，是指通過添加多個空格，使本行的某一符號與上一行的某一符號上下對齊。
這種對齊是被允許的，但是不會做強制要求。
以下是沒有水平對齊和水平對齊的例子;
private int x; // this is fine
private Color color; // this too
private int x; // permitted, but future edits
private Color color; // may leave it unaligned
注意：水平對齊能夠增加代碼的可讀性，但是增加了未來維護代碼的難度?？紤]到維護時只需要改變一行代碼，之前的對齊可以不需要改動。為了對齊，你更有可能改了一行代碼，同時需要更改附近的好幾行代碼，而這幾行代碼的改動，可能又會引起一些為了保持對齊的代碼改動。那原本這行改動，我們稱之為“爆炸半徑”。這種改動，在最壞的情況下可能會導致大量的無意義的工作，即使在最好的情況下，也會影響版本歷史信息，減慢代碼review的速度，引起更多merge代碼沖突的情況。
4.7 分組括號：建議使用
非必須的分組括號只有在編寫代碼者和代碼審核者都認為大家不會因為沒有它而導致代碼理解錯誤的時候，或者它不會使代碼更易理解的時候才能省略。沒有理由認為所有閱讀代碼的人都能記住所有java運算符的優先級。
4.8 特殊結構
4.8.1 枚舉類型
每個逗號后接一個枚舉變量，不要求換行。
枚舉類型，如果沒有函數和javadoc，處理格式是可以按照數組初始化來處理。
例子：
private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }
枚舉類型也是一種類（Class），因此Class類的其他格式要求，也適用于枚舉類型。
4.8.2 變量聲明
4.8.2.1 每次聲明一個變量
不要采用一個聲明，聲明多個變量。例如 int a, b;
4.8.2.2 當需要時才聲明，盡快完成初始化
局部變量不應該習慣性地放在語句塊的開始處聲明，而應該盡量離它第一次使用的地方最近的地方聲明，以減小它們的使用范圍。
局部變量應該在聲明的時候就進行初始化。如果不能在聲明時初始化，也應該盡快完成初始化。
4.8.3 數組
4.8.3.1 數組初始化：可以類似塊代碼處理
所有數組的初始化，都可以采用和塊代碼相同的格式處理。例如以下格式都是允許的：
4.8.3.2 不能像C風格一樣聲明數組
方括號應該是變量類型的一部分，因此不應該和變量名放在一起。例如：應該是String[] args，而不是 String args[] 。
4.8.4 switch語句
術語說明：switch語句是指在switch花括號中，包含了一組或多組語句塊。每組語句塊都由一個或多個switch標簽（例如case FOO：或者 default：）打頭。
4.8.4.1 縮進
和其他語句塊一樣，switch花括號之后縮進兩個字符。
每個switch標簽之后，后面緊接的非標簽的新行，按照花括號相同的處理方式縮進兩個字符。在標簽結束后，恢復到之前的縮進，類似花括號結束。
4.8.4.2 繼續向下執行的注釋
在switch語句中，每個標簽對應的代碼執行完后，都應該通過語句結束（例如：break、continue、return 或拋出異常），否則應該通過注釋說明，代碼需要繼續向下執行下一個標簽的代碼。注釋說明文字只要能說明代碼需要繼續往下執行都可以（通常是 //fall through）。這個注釋在最后一個標簽之后不需要注釋。例如：
4.8.4.3 default標簽需要顯式聲明
每個switch語句中，都需要顯式聲明default標簽。即使沒有任何代碼也需要顯示聲明。
4.8.5 Annotations
Annotations應用到類、函數或者構造函數時，應緊接javadoc之后。每一行只有一個Annotations。
Annotations所在行不受行長度限制，也不需要增加縮進。例如：
@Override
@Nullable
public String getNameIfPresent() { ... }
例外情況：
如果Annotations只有一個，并且不帶參數。則它可以和類或方法名放在同一行。例如：
@Override public int hashCode() { ... }
Annotations應用到成員變量時，也是緊接javadoc之后。不同的是，多個annotations可以放在同一行。例如：
@Partial @Mock DataLoader loader;
對于參數或者局部變量使用Annotations的情況，沒有特定的規范。
4.8.6 注釋
4.8.6.1 語句塊的注釋風格
注釋的縮進與它所注釋的代碼縮進相同。可以采用 /* */ 進行注釋，也可以用 // 進行注釋。當使用 /**/ 進行多行注釋時，每一行都應該以 * 開始， 并且 * 應該上下對齊。
例如：
多行注釋時，如果你希望集成開發環境能自動對齊注釋，你應該使用 /**/， //一般不會自動對齊。
4.8.7 修飾符
多個類和成員變量的修飾符，按Java Lauguage Specification中介紹的先后順序排序。具體是：
public protected private abstract static final transient volatile synchronized native strictfp
五、 命名
5.1 適用于所有命名標識符的通用規范
標示符只應該使用ASCII字母、數字和下劃線，字母大小寫敏感。因此所有的標示符，都應該能匹配正則表達式 \w+ 。
Google Style中，標示符不需要使用特殊的前綴或后綴，例如：name_, mName, s_name 和 kName。
5.2 不同類型的標示符規范
5.2.1 包名
包名全部用小寫字母，通過 . 將各級連在一起。不應該使用下劃線。
5.2.2 類名
類型的命名，采用以大寫字母開頭的大小寫字符間隔的方式（UpperCamelCase）。
class命名一般使用名詞或名詞短語。interface的命名有時也可以使用形容詞或形容詞短語。annotation沒有明確固定的規范。
測試類的命名，應該以它所測試的類的名字為開頭，并在最后加上Test結尾。例如：HashTest 、 HashIntegrationTest。
5.2.3 方法名
方法命名，采用以小寫字母開頭的大小寫字符間隔的方式（lowerCamelCase）。
方法命名一般使用動詞或者動詞短語。
在JUnit的測試方法中，可以使用下劃線，用來區分測試邏輯的名字，經常使用如下的結構：test<MethodUnderTest>_<state> 。例如：testPop_emptyStack 。
測試方法也可以用其他方式進行命名。
5.2.4 常量名
常量命名，全部使用大寫字符，詞與詞之間用下劃線隔開。（CONSTANCE_CASE）。
常量是一個靜態成員變量，但不是所有的靜態成員變量都是常量。在選擇使用常量命名規則給變量命名時，你需要明確這個變量是否是常量。例如，如果這個變量的狀態可以發生改變，那么這個變量幾乎可以肯定不是常量。只是計劃不會發生改變的變量不足以成為一個常量。下面是常量和非常量的例子：
常量一般使用名詞或者名詞短語命名。
5.2.5 非常量的成員變量名
非常量的成員變量命名（包括靜態變量和非靜態變量），采用lowerCamelCase命名。
一般使用名詞或名詞短語。
5.2.6 參數名
參數命名采用lowerCamelCase命名。
應該避免使用一個字符作為參數的命名方式。
5.2.7 局部變量名
局部變量采用lowerCamelCase命名。它相對于其他類型的命名，可以采用更簡短寬松的方式。
但即使如此，也應該盡量避免采用單個字母進行命名的情況，除了在循環體內使用的臨時變量。
即使局部變量是final、不可改變的，它也不能被認為是常量，也不應該采用常量的命名方式去命名。
5.2.8 類型名
類型名有兩種命名方式：
a、單獨一個大寫字母，有時后面再跟一個數字。（例如，E、T、X、T2）。
b、像一般的class命名一樣（見5.2.2節），再在最后接一個大寫字母。（例如，RequestT、FooBarT）。
5.3 Camel case的定義
有時一些短語被寫成Camel case的時候可以有多種寫法。例如一些縮寫詞匯，或者一些組合詞：IPv6 或者 iOS 等。
為了統一寫法，Google style給出了一種幾乎可以確定為一種的寫法。
a、將字符全部轉換為ASCII字符，并且去掉 ' 等符號。例如，"Müller's algorithm" 被轉換為 "Muellers algorithm" 。
b、將上一步轉換的結果拆分成一個一個的詞語。從空格處和從其他剩下的標點符號處劃分。
注意：一些已經是Camel case的詞語，也應該在這個時候被拆分。（例如 AdWords 被拆分為 ad words）。但是例如iOS之類的詞語，它其實不是一個Camel case的詞語，而是人們慣例使用的一個詞語，因此不用做拆分。
c、經過上面兩部后，先將所有的字母轉換為小寫，再把每個詞語的第一個字母轉換為大寫。
d、最后，將所有詞語連在一起，形成一個標示符。
注意：詞語原來的大小寫規則，應該被完全忽略。以下是一些例子：
* 號表示可以接受，但是不建議使用。
注意，有些詞語在英文中，可以用 - 連接使用，也可以不使用 - 直接使用。例如 “nonempty”和 “non-empty”都是可以的。因此，方法名字為checkNonempty 或者checkNonEmpty 都是可以的。
六、編程實踐
6.1 @override 都應該使用
@override annotations只要是符合語法的，都應該使用。
6.2 異常捕獲 不應該被忽略
一般情況下，catch住的異常不應該被忽略，而是都需要做適當的處理。例如將錯誤日志打印出來，或者如果認為這種異常不會發生，則應該作為斷言異常重新拋出。
如果這個catch住的異常確實不需要任何處理，也應該通過注釋做出說明。例如：
例外：在測試類里，有時會針對方法是否會拋出指定的異常，這樣的異常是可以被忽略的。但是這個異常通常需要命名為： expected。例如：
6.3 靜態成員的訪問：應該通過類，而不是對象
當一個靜態成員被訪問時，應該通過class名去訪問，而不應該使用這個class的具體實例對象。例如：
6.4 不使用Finalizers 方法
重載Object的finalize方法是非常非常罕見的。
注意：不應該使用這以方法。如果你認為你必須使用，請先仔細閱讀并理解 Effective Java 第七條 “Avoid Finalizers”。然后不要使用它。
七、Javadoc
7.1 格式規范
7.1.1 通用格式
最基本的javadoc的通用格式如下例：
或者為單行格式：
通用格式在任何時候使用都是可以的。當javadoc塊只有一行時，可以使用單行格式來替代通用格式。
7.1.2 段落
空白行：是指javadoc中，上下兩個段落之間只有上下對齊的 * 字符的行。每個段落的第一行在第一個字符之前，有一個<p>標簽，并且之后不要有任何空格。
7.1.3 @從句
所有標準的@從句，應該按照如下的順序添加：@param、@return、@throws、@deprecated。并且這四種@從句，不應該出現在一個沒有描述的Javadoc塊中。
當@從句無法在一行寫完時，應該斷行。延續行在第一行的@字符的位置，縮進至少4個字符單位。
7.2 摘要片段
每個類或者成員的javadoc，都是由一個摘要片段開始的。這個片段非常重要。因為它是類或者方法在使用時唯一能看到的文本說明。
主要摘要只是一個片段，應該是一個名詞短語或者動詞短語，而不應該是一個完整的句子。但是它應該像一個完整的句子一樣使用標點符號。
注意：一種常見的錯誤是以這種形式使用javadoc：/** @return the customer ID */.這是不對的。應該改為：/** Returns the customer ID. */.
7.3 何處應該使用Javadoc
至少，Javadoc應該應用于所有的public類、public和protected的成員變量和方法。和少量例外的情況。例外情況如下。
7.3.1 例外：方法本身已經足夠說明的情況
當方法本身很顯而易見時，可以不需要javadoc。例如：getFoo。沒有必要加上javadoc說明“Returns the foo”。
單元測試中的方法基本都能通過方法名，顯而易見地知道方法的作用。因此不需要增加javadoc。
注意：有時候不應該引用此例外，來省略一些用戶需要知道的信息。例如：getCannicalName 。當大部分代碼閱讀者不知道canonical name是什么意思時，不應該省略Javadoc,認為只能寫/** Returns the canonical name. */ 。
7.3.2 例外：重載方法
重載方法有時不需要再寫Javadoc。
7.3.3 例外：可選的javadoc
一些在包外不可見的class和成員變量或方法，根據需要，也可以使用javadoc。當一個注釋用以說明這個類、變量或者方法的總體目標或行為時，可以使用Javadoc。
轉載請注明出處：http://www.tkk7.com/zh-weir/archive/2014/02/08/409608.html