一些沒有沒有說明的規範，在這裡解析一下，也方便自己的理解。
一、程式設計規約
- 【強制】 程式碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。
**解析：**因為系統底層的一些程式碼會包含_或者$，用這個開頭或者結尾容易產生一些不容易排查的衝突。
- 【強制】 程式碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。
反例: DaZhePromotion [打折] / getPingfenByName() [評分] / int 某變數 = 3
正例: alibaba / taobao / youku / hangzhou 等國際通用的名稱，可視同英文。
**解析：**正確的英文拼寫和語法可以讓閱讀者易於理解，避免歧義。注意，即使純拼音命名方式 也要避免採用。
- 【強制】中括號是陣列型別的一部分，陣列定義如下:String[] args; 反例:請勿使用String args[]的方式來定義。
**解析：**因為通過“型別 + 變數名”的方式更加容易理解，而中括號屬於陣列型別的一部分。
- 【強制】不允許出現任何魔法值(即未經定義的常量)直接出現在程式碼中。
反例: String key="Id#taobao_"+tradeId;cache.put(key, value);
**解析：**因為直接使用魔法值，別人不能很直接的看到該常量的含義。
- 【強制】縮排採用 4 個空格，禁止使用 tab 字元。
**解析：**因為不同編譯器對tab的解析可能不一樣，混用的話就不易於檢視。
- 【強制】IDE的text file encoding設定為UTF-8; IDE中檔案的換行符使用Unix格式， 不要使用 windows 格式。
**解析：**這是為了保持程式碼在不同平臺的都可以保持良好的格式。
- 【強制】相同引數型別，相同業務含義，才可以使用 Java 的可變引數，避免使用 Object。
**解析：**可變引數雖然使用方便，但是在大型專案中可讀性和可維護性就變得很差了。
- 【強制】Object 的 equals 方法容易拋空指標異常，應使用常量或確定有值的物件來呼叫 equals。
正例: "test".equals(object);
反例: object.equals("test");
說明:推薦使用java.util.Objects#equals (JDK7引入的工具類)
**解析：**Objects.equals(a,b)的使用就完全可以避免空指標異常了，但是如果a和b都為null的話，返回true。
- 【強制】所有的相同型別的包裝類物件之間值的比較，全部使用 equals 方法比較。
說明:對於Integer var=?在-128至127之間的賦值，Integer物件是在 IntegerCache.cache 產生，會複用已有物件，這個區間內的 Integer 值可以直接使用==進行 判斷，但是這個區間之外的所有資料，都會在堆上產生，並不會複用已有物件，這是一個大坑，推薦使用 equals 方法進行判斷。
**解析：**其實上面已經說得很清楚了，當Integer包裝類在-128到127之間，直接指向緩衝池，超過這個範圍會重新建立物件，所以==是不相等的。
- 【強制】構造方法裡面禁止加入任何業務邏輯，如果有初始化邏輯，請放在 init 方法中。
**解析：**當構造方法加入邏輯之後，這個物件的重新性就被大大降低了。
- 【推薦】慎用 Object 的 clone 方法來拷貝物件。
說明:物件的 clone 方法預設是淺拷貝，若想實現深拷貝需要重寫 clone 方法實現屬性物件 的拷貝。
解析： 淺拷貝，即僅拷貝物件中基本資料型別的成員屬性，如果成員屬性引用了其他物件，則拷貝出的物件副本中的這些成員屬性引用的還是同一個物件。深拷貝則是被拷貝物件的成員屬性引用的其他物件也是拷貝出的副本。
- 【強制】關於 hashCode 和 equals 的處理，遵循如下規則:
-
只要重寫equals，就必須重寫hashCode。
-
因為Set儲存的是不重複的物件，依據hashCode和equals進行判斷，所以Set儲存的 物件必須重寫這兩個方法。
-
如果自定義物件做為Map的鍵，那麼必須重寫hashCode和equals。
正例:String 重寫了 hashCode 和 equals 方法，所以我們可以非常愉快地使用 String 物件 作為 key 來使用。
**解析：**因為hashCode和equals是配合起來使用的，先定位物件的hash值連結串列，在equals物件才能唯一標識物件。
編輯到這我發現了有人已經做了這件事了，而且感覺做得挺好，我就不繼續寫了。