個人整合了一些開發中常見的規範,僅供參考。
源碼檔案編碼應為UTF-8。
任何需要逸出字元串表示的字元(例如\b, \t, \n, \f, \r, \’, \等),採用這種逸出字元串的方式表示。
整個源碼檔案中最上面的部分應該有以下四塊內容,且每個部分之間以一行空行分隔。 1.License或者copyright聲明資訊。 2.包聲明語句,且包聲明沒有長度限制,單行長度限制規範,不適用於包聲明。 3.import語句,而且不應使用萬用字元import。所有靜態匯入(static import)為一組,非靜態匯入為一組。如果同時存在靜態匯入與非靜態匯入,則以一個空白行分隔。 4.class類聲明,每個源碼檔案中只能有一個頂級class。類成員順序要有邏輯性。當一個類有多個建構函式或多個同名的方法時,這個函數要寫在一些,中間不要有其它代碼。
格式規範上面,可以整合在format裡面。對於語句塊的規範,如下。 1.大括弧前沒有換行。 2.開頭大括弧後換行。 3.結束大括弧前換行。 4.如果右括弧結束一個語句塊或者函數體、建構函式體或者有命名的類體,則需要換行。例如,當右括弧後面接else或者逗號時,不應該換行。 5.一個空的語句塊,可以在大括弧開始之後真接接結束大括弧,中間不需要空格或換行。但是當一個由幾個語句塊聯合組成的語句塊時,則需要換行。(例如:if/else 或try/catch/finally) 6.對於語句塊的縮排,每當一個新的語句塊產生,縮排就增加兩個空格。當這個語句塊結束時,縮排恢複到上一層級的縮排格數。縮排要求對整個語句塊中的代碼和注釋都適用。 7.每句代碼的結束都需要換行。 8.Java代碼的單行限制長度為100個字元。除以下情況,超出此上限的行必須進行換行。設定“Line Wrapping”,修改其下的“Maximum line width”的數值。 9.當斷行之後,在第一行之後的行,我們叫做延續行。每一個延續行在第一行的基礎上至少縮排四個字元。當原行之後有多個延續行的情況,縮排可以大於4個字元。如果多個延續行之間由同樣的文法元素斷行,它們可以採用相同的縮排。 -
對於代碼的水平空白,有如下的情況。 1.所有保留的關鍵字與緊接它之後的位於同一行的左括弧之間需要用空格隔開。(例如if、for、catch) 2.所有保留的關鍵字與在它之前的右花括弧之間需要空格隔開。(例如else、catch) 3.逗號、冒號、分號和右括弧之後,需要空格隔開。 4.// 雙斜線開始一行注釋時。雙斜線兩邊都應該用空格隔開。並且可使用多個空格,但是不做強制要求。 5.變數聲明時,變數類型和變數名之間需要用空格隔開。 6.初始化一個數組時,花括弧之間可以用空格隔開,也可以不使用。(例如:new int[] {5, 6} 和 new int[] { 5, 6 } 都可以)
對於變數處理,有如下的情況。 1.不要採用一個聲明,聲明多個變數。例如 int a, b;。 2.局部變數不應該習慣性地放在語句塊的開始處聲明,而應該盡量離它第一次使用的地方最近的地方聲明,以減小它們的使用範圍。 3.局部變數應該在聲明的時候就進行初始化。如果不能在聲明時初始化,也應該儘快完成初始化。
多行注釋時,如果你希望整合式開發環境能自動對齊注釋,你應該使用 /**/, //一般不會自動對齊。
long 值整型常量使用大寫L尾碼,從來沒有小寫(避免與數字1混淆)。例如:3000000000L而非3000000000l。
命名相關的規範。 1.包名全部用小寫字母,通過 . 將各級連在一起。不應該使用底線。如com.example.deepspace。 2.類型的命名,採用以大寫字母開頭的大小寫字元間隔的方式(UpperCamelCase)。測試類別的命名,應該以它所測試的類的名字為開頭,並在最後加上Test結尾。例如:HashTest 、 HashIntegrationTest。 3.方法命名一般使用動詞或者動詞短語,採用以小寫字母開頭的大小寫字元間隔的方式(lowerCamelCase)。 4.在JUnit的測試方法中,可以使用底線,用來區分測試邏輯的名字,經常使用如下的結構:test_。例如:testPop_emptyStack 。 5.常量一般使用名詞或者名詞短語命名。全部使用大寫字元,詞與詞之間用底線隔開。(CONSTANCE_CASE)。 6.非常量的成員變數命名(包括靜態變數和非靜態變數),採用lowerCamelCase命名。一般使用名詞或名詞短語。 7.參數命名採用lowerCamelCase命名。應該避免使用一個字元等作為參數的命名方式。 8.局部變數採用lowerCamelCase命名。它相對於其他類型的命名,可以採用更簡短寬鬆的方式。 9.即使局部變數是final、不可改變的,它也不能被認為是常量,也不應該採用常量的命名方式去命名。 10.類型名可以有兩種命名方式:一.單獨一個大寫字母,有時後面再跟一個數字。(例如,E、T、X、T2)。二.像一般的class命名一樣(見5.2.2節),再在最後接一個大寫字母。(例如,RequestT、FooBarT)。
最佳實務。 1.包名全部用小寫字母,通過 . 將各級連在一起。不應該使用底線。如com.example.deepspace。 2.一般情況下,catch住的異常不應該被忽略,而是都需要做適當的處理。例如將錯誤記錄檔列印出來,或者如果認為這種異常不會發生,則應該作為斷言異常重新拋出。如果這個catch住的異常確實不需要任何處理,也應該通過注釋做出說明。 3.當一個靜態成員被訪問時,應該通過class名去訪問,而不應該使用這個class的具體執行個體對象。 4.儘可能少用甚至不使用Finalizers 方法。
針對 javadoc。 1.注釋的通用格式:當javadoc塊只有一行時,可以使用單行格式來替代通用格式。 2.空白行:是指javadoc中,上下兩個段落之間只有上下對齊的 * 字元的行。每個段落的第一行在第一個字元之前,有一個標籤,並且之後不要有任何空格。 3.@從句:所有標準的@從句,應該按照如下的順序添加:@param、@return、@throws、@deprecated。並且這四種@從句,不應該出現在一個沒有描述的Javadoc塊中。當@從句無法在一行寫完時,應該斷行。延續行在第一行的@字元的位置,縮排至少4個字元單位。 4.摘要片段:主要摘要只是一個片段,應該是一個名詞短語或者動詞短語,而不應該是一個完整的句子。但是它應該像一個完整的句子一樣使用標點符號。一種常見的錯誤是以這種形式使用javadoc:/* @return the customer ID /.這是不對的。應該改為:/* Returns the customer ID. /。
針對 哪些地方不使用javadoc。 1.當方法本身很顯而易見時,可以不需要javadoc。例如:getFoo。沒有必要加上javadoc說明“Returns the foo”。 2.重載方法有時不需要再寫Javadoc。 3.一些在包外不可見的class和成員變數或方法,根據需要,也可以使用javadoc。 4.當一個注釋用以說明這個類、變數或者方法的總體目標或行為時,該注釋應使用Javadoc(使用/**)