1.Resource文件

命名

遵循前綴表明類型的習慣，形如type_foo_bar.xml耸袜。如：fragment_contact_details.xml友多，view_primary_button.xml，activity_main.xml堤框。

組織布局文件

遵循以下規(guī)則來排版你的布局文件：

• 每一個屬性一行域滥，縮進4個空格
• android:id 總是作為第一個屬性
• android:layout_**** 屬性在上邊
• style 屬性在底部
• 關(guān)閉標簽 />單獨起一行，有助于調(diào)整和添加新的屬性
• 考慮使用Designtime attributes 設(shè)計時布局屬性，Android Studio已經(jīng)提供支持，而不是硬編碼android:text
  (譯者注：墻內(nèi)也可以參考stormzhang的這篇博客鏈接)

※使用IDE的快捷鍵幫助代碼格式化更為高效颓芭，Android Studio：Ctrl+Alt+L， Eclipse：先卸載Eclipse并安裝Android Studio然后參考前面

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
     xmlns:android="http://schemas.android.com/apk/res/android"
     xmlns:tools="http://schemas.android.com/tools"
     android:layout_width="match_parent"
     android:layout_height="match_parent"
     android:orientation="vertical"
     >
     <TextView
          android:id="@+id/name"
          android:layout_width="match_parent"
          android:layout_height="wrap_content"
          android:layout_alignParentRight="true"
          android:text="@string/name"
          style="@style/FancyText"
          />
     <include layout="@layout/reusable_part" />
</LinearLayout>

作為一個經(jīng)驗法則,android:layout_******屬性應(yīng)該在layout中定義,同時其它屬性android:******應(yīng)放在style中言缤。此規(guī)則也有例外，不過大體工作 的很好。這個思想整體是保持layout屬性(positioning, margin, sizing) 和content屬性在布局文件中舷手，同時將所有的外觀細節(jié)屬性（colors, padding, font）放在style文件中着倾。

這里我們需要注意以下情況：

• android:id 明顯應(yīng)該在 layout 文件中
• layout 文件中 android:orientation 對于一個LinearLayout布局通常更有意義
• android:text 由于是定義內(nèi)容拾酝，應(yīng)該放在 layout 文件中
• 有時候?qū)ndroid:layout_width 和 android:layout_height 屬性放到一個style中作為一個通用的風格中更有意義，但是默認情況下這些應(yīng)該放到layout文件中

合理的使用Style文件

幾乎每個項目都需要適當?shù)氖褂胹tyle文件屈呕，因為對于同一個應(yīng)用來說，為了保持風格的統(tǒng)一棺亭，重復(fù)的外觀是很常見的虎眨。例如：

<style name="ContentText">
       <item name="android:textSize">@dimen/font_normal</item>
       <item name="android:textColor">@color/basic_black</item>
</style>

應(yīng)用到TextView 中：

<TextView
       android:layout_width="wrap_content"
       android:layout_height="wrap_content"
       android:text="@string/price"
       style="@style/ContentText"
       />

你也可以為其他控件做同樣的事情，而且你可以做得更多镶摘。將一組相關(guān)的和重復(fù)android:****的屬性放到一個通用的style中嗽桩，這樣在項目的開發(fā)維護階段都能為你省很多事。

將一個大的style文件分割成多個文件

你可以有多個styles.xml文件凄敢。Android SDK支持其它文件碌冶，styles這個文件名稱并沒有作用，起作用的是在文件 里xml的<style>標簽涝缝。因此你可以有多個style文件扑庞。如：styles.xml，style_home.xml拒逮，style_item_details.xml,styles_forms.xml罐氨。 這樣就很好的將style文件模塊化。不用于資源文件路徑需要為系統(tǒng)構(gòu)建起的有意義滩援，在res/values目錄下的文件可以任意命名栅隐。

colors.xml只是一個調(diào)色板

在你的colors.xml文件中應(yīng)該只是映射顏色的名稱一個RGBA值，而沒有其它的玩徊。不要使用它為不同的按鈕來定義RGBA值租悄。
錯誤例子：

<resources>
       <color name="button_foreground">#FFFFFF</color>
       <color name="button_background">#2A91BD</color>
       <color name="comment_background_inactive">#5F5F5F</color>
       <color name="comment_background_active">#939393</color>
       <color name="comment_foreground">#FFFFFF</color>
       <color name="comment_foreground_important">#FF9D2F</color>
</resources>

向應(yīng)用設(shè)計者那里要這個調(diào)色板，名稱不需要跟"green", "blue", 等等相同恩袱。 "brand_primary", "brand_secondary", "brand_negative" 這樣的名字也是完全可以接受的泣棋。 像這樣規(guī)范的顏色很容易修改或重構(gòu)，會使應(yīng)用一共使用了多少種不同的顏色變得非常清晰畔塔。 通常一個具有審美價值的UI來說外傅，減少使用顏色的種類是非常重要的。

像對待colors.xml一樣對待dimens.xml文件

與定義顏色調(diào)色板一樣俩檬，你同時也應(yīng)該定義一個空隙間隔和字體大小的“調(diào)色板”萎胰。 一個好的例子，如下所示：

<resources>
       <!-- font sizes -->
       <dimen name="font_larger">22sp</dimen>
       <dimen name="font_large">18sp</dimen>
       <dimen name="font_normal">15sp</dimen>
       <dimen name="font_small">12sp</dimen>

       <!-- typical spacing between two views -->
       <dimen name="spacing_huge">40dp</dimen>
       <dimen name="spacing_large">24dp</dimen>
       <dimen name="spacing_normal">14dp</dimen>
       <dimen name="spacing_small">10dp</dimen>
       <dimen name="spacing_tiny">4dp</dimen>

       <!-- typical sizes of views -->
       <dimen name="button_height_tall">60dp</dimen>
       <dimen name="button_height_normal">40dp</dimen>
       <dimen name="button_height_short">32dp</dimen>
</resources>

布局時在寫 margins 和 paddings 時棚辽，你應(yīng)該使用spacing_****尺寸格式來布局技竟，而不是像對待String字符串一樣直接寫值。 這樣寫會非常有感覺屈藐，會使組織和改變風格或布局是非常容易榔组。

避免深層次的視圖結(jié)構(gòu)

有時候為了擺放一個視圖熙尉，你可能嘗試添加另一個LinearLayout。你可能使用這種方法解決：

<LinearLayout
       android:layout_width="match_parent"
       android:layout_height="match_parent"
       android:orientation="vertical" >
       <RelativeLayout ... >
              <LinearLayout ... >
                     <LinearLayout ... >
                            <LinearLayout ... >
                            </LinearLayout>
                     </LinearLayout>
              </LinearLayout>
       </RelativeLayout>
</LinearLayout>

即使你沒有非常明確的在一個layout布局文件中這樣使用搓扯，如果你在Java文件中從一個view inflate（這個inflate翻譯不過去检痰，大家理解就行） 到其他views當中，也是可能會發(fā)生的锨推。

可能會導(dǎo)致一系列的問題铅歼。你可能會遇到性能問題，因為處理起需要處理一個復(fù)雜的UI樹結(jié)構(gòu)换可。 還可能會導(dǎo)致以下更嚴重的問題StackOverflowError.

因此盡量保持你的視圖tree：學習如何使用RelativeLayout, 如何 optimize 你的布局 和如何使用 <merge>
標簽.

小心關(guān)于WebViews的問題

如果你必須顯示一個web視圖椎椰， 比如說對于一個新聞文章，避免做客戶端處理HTML的工作沾鳄， 最好讓后端工程師協(xié)助慨飘，讓他返回一個 "純" HTML。 WebViews 也能導(dǎo)致內(nèi)存泄露 當保持引他們的Activity译荞，而不是被綁定到ApplicationContext中的時候瓤的。 當使用簡單的文字或按鈕時，避免使用WebView吞歼，這時使用TextView或Buttons更好堤瘤。

2.Java文件

文件名

源文件以其最頂層的類名來命名，大小寫敏感浆熔，文件擴展名為.java本辐。

編碼格式

源文件編碼格式為UTF-8。

特殊字符

1.空白字符

除了行結(jié)束符序列医增，ASCII水平空格字符(0x20慎皱，即空格)是源文件中唯一允許出現(xiàn)的空白字符，這意味著：

• 所有其它字符串中的空白字符都要進行轉(zhuǎn)義叶骨。
• 制表符不用于縮進茫多。

2.特殊轉(zhuǎn)義序列

對于具有特殊轉(zhuǎn)義序列的任何字符(\b, \t, \n, \f, \r, ", '及)，我們使用它的轉(zhuǎn)義序列忽刽，而不是相應(yīng)的八進制(比如\012)或Unicode(比如\u000a)轉(zhuǎn)義天揖。

3.非ASCII字符

對于剩余的非ASCII字符，是使用實際的Unicode字符(比如∞)跪帝，還是使用等價的Unicode轉(zhuǎn)義符(比如\u221e)今膊，取決于哪個能讓代碼更易于閱讀和理解。
Tip: 在使用Unicode轉(zhuǎn)義符或是一些實際的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褐着，對于非打印字符坷澡，使用轉(zhuǎn)義，并在必要時寫上注釋

Tip: 永遠不要由于害怕某些程序可能無法正確處理非ASCII字符而讓你的代碼可讀性變差含蓉。當程序無法正確處理非ASCII字符時频敛，它自然無法正確運行， 你就會去fix這些問題的了谴餐。(言下之意就是大膽去用非ASCII字符姻政，如果真的有需要的話)

源文件結(jié)構(gòu)

1.許可證或版權(quán)信息

如果一個文件包含許可證或版權(quán)信息呆抑，那么它應(yīng)當被放在文件最前面岂嗓。

2.package語句

package語句不換行，列限制(4.4節(jié))并不適用于package語句鹊碍。(即package語句寫在一行里)

3.import語句

• import不要使用通配符 即不要出現(xiàn)類似這樣的import語句：import java.util.*厌殉；
• 不要換行 import語句不換行，列限制(4.4節(jié))并不適用于import語句侈咕。(每個import語句獨立成行)公罕；
• 順序和間距 import語句可分為以下幾組，按照這個順序耀销，每組由一個空行分隔：
  ①所有的靜態(tài)導(dǎo)入獨立成組
  ②com.google imports(僅當這個源文件是在com.google包下)
  ③第三方的包楼眷。每個頂級包為一組，字典序熊尉。例如：android, com, junit, org, sun
  ④java imports
  ⑤javax imports
  組內(nèi)不空行罐柳，按字典序排列。

4.類聲明

• 只有一個頂級類聲明 每個頂級類都在一個與它同名的源文件中(當然狰住，還包含.java后綴)张吉。
  例外：package-info.java，該文件中可沒有package-info類催植。
• 類成員順序
  類的成員順序?qū)σ讓W性有很大的影響肮蛹，但這也不存在唯一的通用法則。不同的類對成員的排序可能是不同的创南。 最重要的一點伦忠，每個類應(yīng)該以某種邏輯去排序它的成員，維護者應(yīng)該要能解釋這種排序邏輯稿辙。比如缓苛， 新的方法不能總是習慣性地添加到類的結(jié)尾，因為這樣就是按時間順序而非某種邏輯來排序的。
• 重載：永不分離
  當一個類有多個構(gòu)造函數(shù)未桥，或是多個同名方法笔刹，這些函數(shù)/方法應(yīng)該按順序出現(xiàn)在一起，中間不要放進其它函數(shù)/方法冬耿。

5.大括號

• 使用大括號(即使是可選的) 大括號與if, else, for, do, while語句一起使用舌菜，即使只有一條語句(或是空)，也應(yīng)該把大括號寫上亦镶。
• 非空塊：K & R 風格 對于非空塊和塊狀結(jié)構(gòu)日月，大括號遵循Kernighan和Ritchie風格 (Egyptian brackets):
  ①左大括號前不換行
  ②左大括號后換行
  ③右大括號前換行
  ④如果右大括號是一個語句缤骨、函數(shù)體或類的終止爱咬，則右大括號后換行; 否則不換行蜂绎。例如找岖，如果右大括號后面是else或逗號帖旨，則不換行
  示例：

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

enum類有一些例外

• 空塊：可以用簡潔版本 一個空的塊狀結(jié)構(gòu)里什么也不包含积暖，大括號可以簡潔地寫成{}沼填，不需要換行刽脖。例外：如果它是一個多塊語句的一部分(if/else 或 try/catch/finally) 忌愚，即使大括號內(nèi)沒內(nèi)容曲管，右大括號也要換行。
  示例：

void doNothing() {}

6.塊縮進：2個空格

每當開始一個新的塊硕糊，縮進增加2個空格院水，當塊結(jié)束時，縮進返回先前的縮進級別简十∶誓常縮進級別適用于代碼和注釋。

7.一行一個語句

每個語句后要換行螟蝙。

8.列限制：80或100

一個項目可以選擇一行80個字符或100個字符的列限制恢恼，除了下述例外，任何一行如果超過這個字符數(shù)限制胰默，必須自動換行场斑。
例外：

• 不可能滿足列限制的行(例如，Javadoc中的一個長URL牵署，或是一個長的JSNI方法參考)
• package和import語句
• 注釋中那些可能被剪切并粘貼到shell中的命令行

9.自動換行

一般情況下漏隐，一行長代碼為了避免超出列限制(80或100個字符)而被分為多行，我們稱之為自動換行(line-wrapping)奴迅。
我們并沒有全面青责，確定性的準則來決定在每一種情況下如何自動換行。很多時候，對于同一段代碼會有好幾種有效的自動換行方式脖隶。
Tip: 提取方法或局部變量可以在不換行的情況下解決代碼過長的問題(是合理縮短命名長度吧)

• 從哪里斷開 自動換行的基本準則是：更傾向于在更高的語法級別處斷開扁耐。
  ①如果在非賦值運算符處斷開，那么在該符號前斷開(比如+产阱，它將位于下一行)做葵。注意：這一點與Google其它語言的編程風格不同(如C++和JavaScript)。 這條規(guī)則也適用于以下“類運算符”符號：點分隔符(.)心墅，類型界限中的&（<T extends Foo & Bar>)酿矢，catch塊中的管道符號(catch (FooException | BarException e)
  ②如果在賦值運算符處斷開，通常的做法是在該符號后斷開(比如=怎燥，它與前面的內(nèi)容留在同一行)瘫筐。這條規(guī)則也適用于foreach語句中的分號
  ③方法名或構(gòu)造函數(shù)名與左括號留在同一行
  ④逗號(,)與其前面的內(nèi)容留在同一行
• 自動換行時縮進至少+4個空格 自動換行時，第一行后的每一行至少比第一行多縮進4個空格(注意：制表符不用于縮進)铐姚。當存在連續(xù)自動換行時策肝，縮進可能會多縮進不只4個空格(語法元素存在多級時)。一般而言隐绵，兩個連續(xù)行使用相同的縮進當且僅當它們開始于同級語法元素之众。

10.空白

• 垂直空白 以下情況需要使用一個空行：
  ①類內(nèi)連續(xù)的成員之間：字段，構(gòu)造函數(shù)依许，方法，嵌套類峭跳，靜態(tài)初始化塊膘婶，實例初始化塊
  例外：兩個連續(xù)字段之間的空行是可選的，用于字段的空行主要用來對字段進行邏輯分組蛀醉。
  ②在函數(shù)體內(nèi)悬襟，語句的邏輯分組間使用空行
  ③類內(nèi)的第一個成員前或最后一個成員后的空行是可選的(既不鼓勵也不反對這樣做，視個人喜好而定)
  ④要滿足本文檔中其他節(jié)的空行要求(比如：前面講的import語句)
  多個連續(xù)的空行是允許的拯刁，但沒有必要這樣做(我們也不鼓勵這樣做)脊岳。
• 水平空白 除了語言需求和其它規(guī)則，并且除了文字垛玻，注釋和Javadoc用到單個空格割捅，單個ASCII空格也出現(xiàn)在以下幾個地方：
  ①分隔任何保留字與緊隨其后的左括號(()(如if, for catch等)
  ②分隔任何保留字與其前面的右大括號(})(如else, catch)
  ③在任何左大括號前({)
  兩個例外：@SomeAnnotation({a, b})(不使用空格)；String[][] x = foo夭谤；(大括號間沒有空格棺牧，見下面的Note)
  ④在任何二元或三元運算符的兩側(cè)。這也適用于以下“類運算符”符號
  類型界限中的&(<T extends Foo & Bar>)
  catch塊中的管道符號(catch (FooException | BarException e)
  foreach語句中的分號
  ⑤在, : ;及右括號())后
  ⑥如果在一條語句后做注釋朗儒，則雙斜杠(//)兩邊都要空格颊乘。這里可以允許多個空格参淹，但沒有必要
  ⑦類型和變量之間：List list
  ⑧數(shù)組初始化中，大括號內(nèi)的空格是可選的乏悄，即new int[] {5, 6}和new int[] { 5, 6 }都是可以的
  Tip：這個規(guī)則并不要求或禁止一行的開關(guān)或結(jié)尾需要額外的空格浙值，只對內(nèi)部空格做要求。
• 水平對齊：不做要求 水平對齊指的是通過增加可變數(shù)量的空格來使某一行的字符與上一行的相應(yīng)字符對齊檩小。這是允許的(而且在不少地方可以看到這樣的代碼)开呐，但Google編程風格對此不做要求。即使對于已經(jīng)使用水平對齊的代碼规求，我們也不需要去保持這種風格筐付。
  示例：

       //未對齊
       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

Tip：對齊可增加代碼可讀性，但它為日后的維護帶來問題阻肿⊥咂荩考慮未來某個時候，我們需要修改一堆對齊的代碼中的一行丛塌。 這可能導(dǎo)致原本很漂亮的對齊代碼變得錯位较解。很可能它會提示你調(diào)整周圍代碼的空白來使這一堆代碼重新水平對齊(比如程序員想保持這種水平對齊的風格)， 這就會讓你做許多的無用功赴邻，增加了reviewer的工作并且可能導(dǎo)致更多的合并沖突印衔。(我們選擇不對齊)

11.用小括號來限定組：推薦

除非作者和reviewer都認為去掉小括號也不會使代碼被誤解，或是去掉小括號能讓代碼更易于閱讀姥敛，否則我們不應(yīng)該去掉小括號奸焙。 我們沒有理由假設(shè)讀者能記住整個Java運算符優(yōu)先級表。

12.具體結(jié)構(gòu)

• 枚舉類 枚舉常量間用逗號隔開徒溪，換行可選忿偷。沒有方法和文檔的枚舉類可寫成數(shù)組初始化的格式：private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }由于枚舉類也是一個類金顿，因此所有適用于其它類的格式規(guī)則也適用于枚舉類臊泌。
• 變量聲明
  ①每次只聲明一個變量 不要使用組合聲明，比如int a, b;揍拆。
  ②需要時才聲明渠概，并盡快進行初始化 不要在一個代碼塊的開頭把局部變量一次性都聲明了(這是c語言的做法)，而是在第一次需要使用它時才聲明嫂拴。 局部變量在聲明時最好就進行初始化播揪，或者聲明后盡快進行初始化。
  ③在任何左大括號前({)
• 數(shù)組
  ①數(shù)組初始化：可寫成塊狀結(jié)構(gòu) 數(shù)組初始化可以寫成塊狀結(jié)構(gòu)筒狠，比如猪狈，下面的寫法都是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}

**②非C風格的數(shù)組聲明** 中括號是類型的一部分：String[] args， 而非String args[]辩恼。

• switch語句 switch塊的大括號內(nèi)是一個或多個語句組雇庙。每個語句組包含一個或多個switch標簽(case FOO:或default:)谓形，后面跟著一條或多條語句。
  ①縮進 與其它塊狀結(jié)構(gòu)一致疆前，switch塊中的內(nèi)容縮進為2個空格寒跳。每個switch標簽后新起一行，再縮進2個空格竹椒，寫下一條或多條語句童太。
  ②Fall-through：注釋 在一個switch塊內(nèi)，每個語句組要么通過break, continue, return
  或拋出異常來終止胸完，要么通過一條注釋來說明程序?qū)⒗^續(xù)執(zhí)行到下一個語句組书释， 任何能表達這個意思的注釋都是OK的(典型的是用// fall through)。這個特殊的注釋并不需要在最后一個語句組(一般是default)中出現(xiàn)赊窥。示例：

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

**③default的情況要寫出來** 

每個switch語句都包含一個default語句組征冷，即使它什么代碼也不包含。

• 注解(Annotations) 注解緊跟在文檔塊后面誓琼，應(yīng)用于類检激、方法和構(gòu)造函數(shù)，一個注解獨占一行腹侣。這些換行不屬于自動換行(第4.5節(jié)叔收，自動換行)，因此縮進級別不變傲隶。例如：

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

例外：單個的注解可以和簽名的第一行出現(xiàn)在同一行饺律，如：@Override public int hashCode() { ... }；應(yīng)用于字段的注解緊隨文檔塊出現(xiàn)跺株，應(yīng)用于字段的多個注解允許與字段出現(xiàn)在同一行复濒，如：@Partial @Mock DataLoader loader。
參數(shù)和局部變量注解沒有特定規(guī)則乒省。

• 注釋
  ①塊注釋風格 塊注釋與其周圍的代碼在同一縮進級別巧颈。它們可以是/* ... /風格，也可以是// ...風格袖扛。對于多行的/ ... /注釋砸泛，后續(xù)行必須從開始， 并且與前一行的*對齊蛆封。以下示例注釋都是OK的唇礁。

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

• Modifiers 類和成員的modifiers如果存在，則按Java語言規(guī)范中推薦的順序出現(xiàn)惨篱。
  public protected private abstract static final transient volatile synchronized native strictfp

命名約定

1.對所有標識符都通用的規(guī)則

標識符只能使用ASCII字母和數(shù)字盏筐，因此每個有效的標識符名稱都能匹配正則表達式\w+。在Google其它編程語言風格中使用的特殊前綴或后綴砸讳，如name_, mName, s_name和kName琢融，在Java編程風格中都不再使用楷拳。

2.標識符類型的規(guī)則

• 包名 全部小寫，連續(xù)的單詞只是簡單地連接起來吏奸，不使用下劃線欢揖。**
• 類名 類名都以UpperCamelCase。類名通常是名詞或名詞短語奋蔚，接口名稱有時可能是形容詞或形容詞短語∷欤現(xiàn)在還沒有特定的規(guī)則或行之有效的約定來命名注解類型。測試類的命名以它要測試的類的名稱開始泊碑，以Test結(jié)束坤按。例如，HashTest或HashIntegrationTest馒过。風格編寫臭脓。
• 方法名 方法名都以lowerCamelCase風格編寫。方法名通常是動詞或動詞短語腹忽。下劃線可能出現(xiàn)在JUnit測試方法名稱中用以分隔名稱的邏輯組件来累。一個典型的模式是：test<MethodUnderTest>_<state>，例testPop_emptyStack窘奏。 并不存在唯一正確的方式來命名測試方法嘹锁。
• 常量名 常量名命名模式為CONSTANT_CASE，全部字母大寫着裹，用下劃線分隔單詞领猾。

// Constant
sstatic final int NUMBER = 5;
static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(','); 
// because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }
// Not constants
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 Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

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

• 非常量字段名 非常量字段名以lowerCamelCase風格編寫骇扇。這些名字通常是名詞或名詞短語摔竿。
• 參數(shù)名 參數(shù)名以lowerCamelCase風格編寫。參數(shù)應(yīng)該避免用單個字符命名少孝。
• 局部變量名 局部變量名以lowerCamelCase風格編寫继低，比起其它類型的名稱，局部變量名可以有更為寬松的縮寫韭山。雖然縮寫更寬松郁季，但還是要避免用單字符進行命名，除了臨時變量和循環(huán)變量钱磅。即使局部變量是final和不可改變的，也不應(yīng)該把它示為常量似枕，自然也不能用常量的規(guī)則去命名它盖淡。
• 類型變量名 類型變量可用以下兩種風格之一進行命名：
  ①單個的大寫字母，后面可以跟一個數(shù)字(如：E, T, X, T2)
  ②以類命名方式(5.2.2節(jié))凿歼，后面加個大寫的T(如：RequestT, FooBarT)

3.駝峰式命名法(CamelCase)

駝峰式命名法分大駝峰式命名法(UpperCamelCase)和小駝峰式命名法(lowerCamelCase)褪迟。 有時冗恨，我們有不只一種合理的方式將一個英語詞組轉(zhuǎn)換成駝峰形式，如縮略語或不尋常的結(jié)構(gòu)(例如”IPv6”或”iOS”)味赃。Google指定了以下的轉(zhuǎn)換方案掀抹。名字從散文形式(prose form)開始:

• 把短語轉(zhuǎn)換為純ASCII碼，并且移除任何單引號心俗。例如：”Müller’s algorithm”將變成”Muellers algorithm”
• 把這個結(jié)果切分成單詞傲武，在空格或其它標點符號(通常是連字符)處分割開。
  推薦：如果某個單詞已經(jīng)有了常用的駝峰表示形式城榛，按它的組成將它分割開(如”AdWords”將分割成”ad words”)揪利。 需要注意的是”iOS”并不是一個真正的駝峰表示形式，因此該推薦對它并不適用狠持。
• 現(xiàn)在將所有字母都小寫(包括縮寫)疟位，然后將單詞的第一個字母大寫：
  每個單詞的第一個字母都大寫，來得到大駝峰式命名喘垂。
  除了第一個單詞甜刻，每個單詞的第一個字母都大寫，來得到小駝峰式命名正勒。
• 最后將所有的單詞連接起來得到一個標識符罢吃。
  Note：在英語中，某些帶有連字符的單詞形式不唯一昭齐。例如：”nonempty”和”non-empty”都是正確的尿招，因此方法名checkNonempty和checkNonEmpty也都是正確的。

編程實踐

1.@Override：能用則用

只要是合法的阱驾，就把@Override注解給用上就谜。

2.捕獲的異常：不能忽視

除了下面的例子，對捕獲的異常不做響應(yīng)是極少正確的里覆。(典型的響應(yīng)方式是打印日志丧荐，或者如果它被認為是不可能的，則把它當作一個AssertionError重新拋出喧枷。)
如果它確實是不需要在catch塊中做任何響應(yīng)虹统，需要做注釋加以說明(如下面的例子)。

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) {
}

3.靜態(tài)成員：使用類進行調(diào)用

使用類名調(diào)用靜態(tài)的類成員帽借，而不是具體某個對象或表達式珠增。

Foo aFoo = ...;
Foo.aStaticMethod(); // good
aFoo.aStaticMethod(); // bad
somethingThatYieldsAFoo().aStaticMethod(); // very bad

4.Finalizers: 禁用

極少會去重寫Object.finalize
Tip：不要使用finalize超歌。如果你非要使用它，請先仔細閱讀和理解Effective Java 第7條款：“Avoid Finalizers”蒂教，然后不要使用它巍举。

Javadoc

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)凝垛，可以使用單行形式懊悯。

• 段落 空行(即，只包含最左側(cè)星號的行)會出現(xiàn)在段落之間和Javadoc標記(@XXX)之前(如果有的話)苔严。 除了第一個段落定枷，每個段落第一個單詞前都有標簽<\p>，并且它和第一個單詞間沒有空格届氢。
• Javadoc標記 標準的Javadoc標記按以下順序出現(xiàn)：@param, @return, @throws, @deprecated, 前面這4種標記如果出現(xiàn)欠窒，描述都不能為空。 當描述無法在一行中容納退子，連續(xù)行需要至少再縮進4個空格岖妄。

2.摘要片段

每個類或成員的Javadoc以一個簡短的摘要片段開始。這個片段是非常重要的寂祥，在某些情況下荐虐，它是唯一出現(xiàn)的文本，比如在類和方法索引中丸凭。這只是一個小片段福扬，可以是一個名詞短語或動詞短語，但不是一個完整的句子惜犀。它不會以A {@code Foo} is a...或This method returns...開頭, 它也不會是一個完整的祈使句铛碑，如Save the record...。然而虽界，由于開頭大寫及被加了標點汽烦，它看起來就像是個完整的句子。
Tip：一個常見的錯誤是把簡單的Javadoc寫成/** @return the customer ID */莉御，這是不正確的撇吞。它應(yīng)該寫成/** Returns the customer ID. */。

3.哪里需要使用Javadoc

至少在每個public類及它的每個public和protected成員處使用Javadoc礁叔，以下是一些例外：
①例外：不言自明的方法 對于簡單明顯的方法如getFoo牍颈，Javadoc是可選的(即，是可以不寫的)晴圾。這種情況下除了寫“Returns the foo”颂砸，確實也沒有什么值得寫了。單元測試類中的測試方法可能是不言自明的最常見例子了死姚，我們通橙伺遥可以從這些方法的描述性命名中知道它是干什么的，因此不需要額外的文檔說明都毒。
Tip：如果有一些相關(guān)信息是需要讀者了解的色罚，那么以上的例外不應(yīng)作為忽視這些信息的理由。例如账劲，對于方法名getCanonicalName戳护， 就不應(yīng)該忽視文檔說明，因為讀者很可能不知道詞語canonical name指的是什么瀑焦。
②例外：重寫 如果一個方法重寫了超類中的方法腌且，那么Javadoc并非必需的。
③可選的Javadoc 對于包外不可見的類和方法榛瓮，如有需要铺董，也是要使用Javadoc的。如果一個注釋是用來定義一個類禀晓，方法精续，字段的整體目的或行為， 那么這個注釋應(yīng)該寫成Javadoc粹懒，這樣更統(tǒng)一更友好重付。