JAVA編碼規范
文件命名
Java的文件主要有兩種，編程的源代碼與解釋后的字節碼，前者的后綴是.java，后者是.class。Java的文件名是大小寫(xiě)敏感的。
起始注釋
所有的源代碼文件都應該有C語(yǔ)言風(fēng)格的起始注釋?zhuān)谐鲱?lèi)名、版本號、日期和版權信息等，如下所示：
/***************************************************************
*文件名稱(chēng)：*.java
*版本：
*日期：
*作者：
*說(shuō)明：
*類(lèi)說(shuō)明：
*其他說(shuō)明：
**************************************************************/
包和引用聲明
大部分Java源代碼文件的非注釋內容的第一行是包聲明（如果有的話(huà)），然后是引用聲明。需要注意的是，包的名字全部采用小寫(xiě)。
類(lèi)和接口聲明(Class and Interface Declarations)
下表描述了類(lèi)和接口聲明的各個(gè)部分以及它們出現的先后次序。
1.類(lèi)/接口文檔注釋(/**……*/)
該注釋中所需包含的信息，參見(jiàn)"文檔注釋"
2.類(lèi)或接口的聲明
3.類(lèi)/接口實(shí)現的注釋(/*……*/)
如果有必要的話(huà)，該注釋?xiě)魏斡嘘P(guān)整個(gè)類(lèi)或接口的信息，而這些信息又不適合作為類(lèi)/接口文檔注釋。
4.類(lèi)的(靜態(tài))變量
首先是類(lèi)的公共變量，隨后是保護變量，再后是包一級別的變量(沒(méi)有訪(fǎng)問(wèn)修飾符，access modifier)，最后是私有變量。
5.實(shí)例變量
首先是公共級別的，隨后是保護級別的，再后是包一級別的(沒(méi)有訪(fǎng)問(wèn)修飾符)，最后是私有級別的。
6.構造器
7.方法
這些方法應該按功能，而非作用域或訪(fǎng)問(wèn)權限，分組。例如，一個(gè)私有的類(lèi)方法可以置于兩個(gè)公有的實(shí)例方法之間。其目的是為了更便于閱讀和理解代碼。
縮進(jìn)排版：
4個(gè)空格常被作為縮進(jìn)排版的一個(gè)單位?？s進(jìn)的確切解釋并未詳細指定(空格 vs. 制表符)。一個(gè)制表符等于8個(gè)空格(而非4個(gè))。
行長(cháng)度
盡量避免一行的長(cháng)度超過(guò)80個(gè)字符，因為很多終端和工具不能很好處理之。
注意：用于文檔中的例子應該使用更短的行長(cháng)，長(cháng)度一般不超過(guò)70個(gè)字符。
注釋
實(shí)現注釋用以注釋代碼或者實(shí)現細節。文檔注釋從實(shí)現自由(implementation-free)的角度描述代碼的規范。它可以被那些手頭沒(méi)有源碼的開(kāi)發(fā)人員讀懂。
注釋?xiě)挥脕?lái)給出代碼的總括，并提供代碼自身沒(méi)有提供的附加信息。注釋?xiě)搩H包含與閱讀和理解程序有關(guān)的信息。例如，相應的包如何被建立或位于哪個(gè)目錄下之類(lèi)的信息不應包括在注釋中。
在注釋里，對設計決策中重要的或者不是顯而易見(jiàn)的地方進(jìn)行說(shuō)明是可以的，但應避免提供代碼中己清晰表達出來(lái)的重復信息。多余的注釋很容易過(guò)時(shí)。通常應避免那些代碼更新就可能過(guò)時(shí)的注釋。
注意：頻繁的注釋有時(shí)反映出代碼的低質(zhì)量。當你覺(jué)得被迫要加注釋的時(shí)候，考慮一下重寫(xiě)代碼使其更清晰。
注釋不應寫(xiě)在用星號或其他字符畫(huà)出來(lái)的大框里。注釋不應包括諸如制表符和回退符之類(lèi)的特殊字符。
塊注釋通常用于提供對文件，方法，數據結構和算法的描述。塊注釋被置于每個(gè)文件的開(kāi)始處以及每個(gè)方法之前。它們也可以被用于其他地方，比如方法內部。在功能和方法內部的塊注釋?xiě)摵退鼈兯枋龅拇a具有一樣的縮進(jìn)格式。
命名規范
包(Packages) ：包名的后續部分根據不同機構各自?xún)炔康拿幏抖槐M相同。這類(lèi)命名規范可能以特定目錄名的組成來(lái)區分部門(mén)(department)，項目(project)，機器(machine)，或注冊名(login names)。
類(lèi)(Classes)：類(lèi)名是個(gè)一名詞，采用大小寫(xiě)混合的方式，每個(gè)單詞的首字母大寫(xiě)。盡量使你的類(lèi)名簡(jiǎn)潔而富于描述。使用完整單詞，避免縮寫(xiě)詞(除非該縮寫(xiě)詞被更廣泛使用，像URL，HTML)。
接口(Interfaces)：命名規則：大小寫(xiě)規則與類(lèi)名相似。
方法(Methods)：方法名是一個(gè)動(dòng)詞，采用大小寫(xiě)混合的方式，第一個(gè)單詞的首字母小寫(xiě)，其后單詞的首字母大寫(xiě)。
變量(Variables)：除了變量名外，所有實(shí)例，包括類(lèi)，類(lèi)常量，均采用大小寫(xiě)混合的方式，第一個(gè)單詞的首字母小寫(xiě)，其后單詞的首字母大寫(xiě)。變量名不應以下劃線(xiàn)或美元符號開(kāi)頭，盡管這在語(yǔ)法上是允許的。變量名應簡(jiǎn)短且富于描述。變量名的選用應該易于記憶，即，能夠指出其用途。盡量避免單個(gè)字符的變量名，除非是一次性的臨時(shí)變量。臨時(shí)變量通常被取名為i，j，k，m和n，它們一般用于整型；c，d，e，它們一般用于字符型。
實(shí)例變量(Instance Variables)：大小寫(xiě)規則和變量名相似，除了前面需要一個(gè)下劃線(xiàn)。
常量(Constants)：類(lèi)常量和ANSI常量的聲明，應該全部大寫(xiě)，單詞間用下劃線(xiàn)隔開(kāi)。(盡量避免ANSI常量，容易引起錯誤)
編碼方法(摘自msdn）－－看看有好處
編碼方法合并了軟件開(kāi)發(fā)的許多方面。盡管它們通常對應用程序的功能沒(méi)有影響，但它們對于改善對源代碼的理解是有幫助的。這里考慮了所有形式的源代碼，包括編程、腳本撰寫(xiě)、標記和查詢(xún)語(yǔ)言。
不建議將這里定義的編碼方法形成一套固定的編碼標準。相反，它們旨在作為開(kāi)發(fā)特定軟件項目的編碼標準的指南。
編碼方法分為三部分：
命名
對于理解應用程序的邏輯流，命名方案是最有影響力的一種幫助。名稱(chēng)應該說(shuō)明“什么”而不是“如何”。通過(guò)避免使用公開(kāi)基礎實(shí)現（它們會(huì )發(fā)生改變）的名稱(chēng)，可以保留簡(jiǎn)化復雜性的抽象層。例如，可以使用 GetNextStudent()，而不是 GetNextArrayElement()。
命名原則是：選擇正確名稱(chēng)時(shí)的困難可能表明需要進(jìn)一步分析或定義項的目的。使名稱(chēng)足夠長(cháng)以便有一定的意義，并且足夠短以避免冗長(cháng)。唯一名稱(chēng)在編程上僅用于將各項區分開(kāi)。表現力強的名稱(chēng)是為了幫助人們閱讀；因此，提供人們可以理解的名稱(chēng)是有意義的。不過(guò)，請確保選擇的名稱(chēng)符合適用語(yǔ)言的規則和標準。
以下幾點(diǎn)是推薦的命名方法。
例程
避免容易被主觀(guān)解釋的難懂的名稱(chēng)，如對于例程的 AnalyzeThis()，或者對于變量的 xxK8。這樣的名稱(chēng)會(huì )導致多義性，而不僅僅是抽象。
在面向對象的語(yǔ)言中，在類(lèi)屬性的名稱(chēng)中包含類(lèi)名是多余的，如 Book.BookTitle。而是應該使用 Book.Title。
使用動(dòng)詞-名詞的方法來(lái)命名對給定對象執行特定操作的例程，如 CalculateInvoiceTotal()。
在允許函數重載的語(yǔ)言中，所有重載都應該執行相似的函數。對于那些不允許函數重載的語(yǔ)言，建立使相似函數發(fā)生關(guān)系的命名標準。
變量
只要合適，在變量名的末尾追加計算限定符（Avg、Sum、Min、Max、Index）。
在變量名中使用互補對，如 min/max、begin/end 和 open/close。
鑒于大多數名稱(chēng)都是通過(guò)連接若干單詞構造的，請使用大小寫(xiě)混合的格式以簡(jiǎn)化它們的閱讀。另外，為了幫助區分變量和例程，請對例程名稱(chēng)使用 Pascal 大小寫(xiě)處理 (CalculateInvoiceTotal)，其中每個(gè)單詞的第一個(gè)字母都是大寫(xiě)的。對于變量名，請使用 camel 大小寫(xiě)處理 (documentFormatType)，其中除了第一個(gè)單詞外每個(gè)單詞的第一個(gè)字母都是大寫(xiě)的。
布爾變量名應該包含 Is，這意味著(zhù) Yes/No 或 True/False 值，如 fileIsFound。
在命名狀態(tài)變量時(shí)，避免使用諸如 Flag 的術(shù)語(yǔ)。狀態(tài)變量不同于布爾變量的地方是它可以具有兩個(gè)以上的可能值。不是使用 documentFlag，而是使用更具描述性的名稱(chēng)，如 documentFormatType。
即使對于可能僅出現在幾個(gè)代碼行中的生存期很短的變量，仍然使用有意義的名稱(chēng)。僅對于短循環(huán)索引使用單字母變量名，如 i 或 j。
不要使用原義數字或原義字符串，如 For i = 1 To 7。而是使用命名常數，如 For i = 1 To NUM_DAYS_IN_WEEK 以便于維護和理解。
表
在命名表時(shí)，用單數形式表示名稱(chēng)。例如，使用 Employee，而不是 Employees。
在命名表的列時(shí)，不要重復表的名稱(chēng)；例如，在名為 Employee 的表中避免使用名為 EmployeeLastName 的字段。
不要在列的名稱(chēng)中包含數據類(lèi)型。如果后來(lái)有必要更改數據類(lèi)型，這將減少工作量。
Microsoft SQL Server
不要給存儲過(guò)程加 sp 前綴，這個(gè)前綴是為標識系統存儲過(guò)程保留的。
不要給用戶(hù)定義的函數加 fn_ 前綴，這個(gè)前綴是為標識內置函數保留的。
不要給擴展存儲過(guò)程加 xp_ 前綴，這個(gè)前綴是為標識系統擴展存儲過(guò)程保留的。
雜項
盡量減少使用縮寫(xiě)，而是使用以一致方式創(chuàng )建的縮寫(xiě)?？s寫(xiě)應該只有一個(gè)意思；同樣，每個(gè)縮寫(xiě)詞也應該只有一個(gè)縮寫(xiě)。例如，如果用 min 作為 minimum 的縮寫(xiě)，那么在所有地方都應這樣做；不要將 min 又用作 minute 的縮寫(xiě)。
在命名函數時(shí)包括返回值的說(shuō)明，如 GetCurrentWindowName()。
與過(guò)程名一樣，文件和文件夾的名稱(chēng)也應該精確地說(shuō)明它們的用途。
避免對不同的元素重用名稱(chēng)，如名為 ProcessSales() 的例程和名為 iProcessSales 的變量。
在命名元素時(shí)避免同音異義詞（如 write 和 right），以防在檢查代碼時(shí)發(fā)生混淆。
在命名元素時(shí)，避免使用普遍拼錯的詞。另外，應清楚區域拼寫(xiě)之間存在的差異，如 color/colour 和 check/cheque。
避免用印刷標記來(lái)標識數據類(lèi)型，如用 $ 代表字符串或用 % 代表整數。
注釋
軟件文檔以?xún)煞N形式存在：外部的和內部的。外部文檔（如規范、幫助文件和設計文檔）在源代碼的外部維護。內部文檔由開(kāi)發(fā)人員在開(kāi)發(fā)時(shí)在源代碼中編寫(xiě)的注釋組成。
不考慮外部文檔的可用性，由于硬拷貝文檔可能會(huì )放錯地方，源代碼清單應該能夠獨立存在。外部文檔應該由規范、設計文檔、更改請求、錯誤歷史記錄和使用的編碼標準組成。
內部軟件文檔的一個(gè)難題是確保注釋的維護與更新與源代碼同時(shí)進(jìn)行。盡管正確注釋源代碼在運行時(shí)沒(méi)有任何用途，但這對于必須維護特別復雜或麻煩的軟件片段的開(kāi)發(fā)人員來(lái)說(shuō)卻是無(wú)價(jià)的。
以下幾點(diǎn)是推薦的注釋方法：
如果用 C# 進(jìn)行開(kāi)發(fā)，請使用 XML 文檔功能。有關(guān)更多信息，請參見(jiàn)：XML 文檔。
修改代碼時(shí)，總是使代碼周?chē)淖⑨尡３肿钚隆?
在每個(gè)例程的開(kāi)始，提供標準的注釋樣本以指示例程的用途、假設和限制很有幫助。注釋樣本應該是解釋它為什么存在和可以做什么的簡(jiǎn)短介紹。
避免在代碼行的末尾添加注釋?zhuān)恍形沧⑨屖勾a更難閱讀。不過(guò)在批注變量聲明時(shí)，行尾注釋是合適的；在這種情況下，將所有行尾注釋在公共制表位處對齊。
避免雜亂的注釋?zhuān)缫徽行翘?。而是應該使用空白將注釋同代碼分開(kāi)。
避免在塊注釋的周?chē)由嫌∷⒖?。這樣看起來(lái)可能很漂亮，但是難于維護。
在部署之前，移除所有臨時(shí)或無(wú)關(guān)的注釋?zhuān)员苊庠谌蘸蟮木S護工作中產(chǎn)生混亂。
如果需要用注釋來(lái)解釋復雜的代碼節，請檢查此代碼以確定是否應該重寫(xiě)它。盡一切可能不注釋難以理解的代碼，而應該重寫(xiě)它。盡管一般不應該為了使代碼更簡(jiǎn)單以便于人們使用而犧牲性能，但必須保持性能和可維護性之間的平衡。
在編寫(xiě)注釋時(shí)使用完整的句子。注釋?xiě)撽U明代碼，而不應該增加多義性。
在編寫(xiě)代碼時(shí)就注釋?zhuān)驗橐院蠛芸赡軟](méi)有時(shí)間這樣做。另外，如果有機會(huì )復查已編寫(xiě)的代碼，在今天看來(lái)很明顯的東西六周以后或許就不明顯了。
避免多余的或不適當的注釋?zhuān)缬哪牟恢饕膫渥ⅰ?
使用注釋來(lái)解釋代碼的意圖。它們不應作為代碼的聯(lián)機翻譯。
注釋代碼中不十分明顯的任何內容。
為了防止問(wèn)題反復出現，對錯誤修復和解決方法代碼總是使用注釋?zhuān)绕涫窃趫F隊環(huán)境中。
對由循環(huán)和邏輯分支組成的代碼使用注釋。這些是幫助源代碼讀者的主要方面。
在整個(gè)應用程序中，使用具有一致的標點(diǎn)和結構的統一樣式來(lái)構造注釋。
用空白將注釋同注釋分隔符分開(kāi)。在沒(méi)有顏色提示的情況下查看注釋時(shí)，這樣做會(huì )使注釋很明顯且容易被找到。
格式
格式化使代碼的邏輯結構很明顯?；〞r(shí)間確保源代碼以一致的邏輯方式進(jìn)行格式化，這對于您和必須解密源代碼的其他開(kāi)發(fā)人員都有幫助。
以下幾點(diǎn)是推薦的格式化方法。
建立標準的縮進(jìn)大?。ㄈ缢膫€(gè)空格），并一致地使用此標準。用規定的縮進(jìn)對齊代碼節。
在發(fā)布源代碼的硬拷貝版本時(shí)使用 monotype 字體。
在括號對對齊的位置垂直對齊左括號和右括號，如：
for (i = 0; i < 100; i++) { ... }
還可以使用傾斜樣式，即左括號出現在行尾，右括號出現在行首，如：
for (i = 0; i < 100; i++){ ... }
無(wú)論選擇哪種樣式，請在整個(gè)源代碼中使用那個(gè)樣式。
沿邏輯結構行縮進(jìn)代碼。沒(méi)有縮進(jìn)，代碼將變得難以理解，如：
If ... Then If ... Then ... Else End If Else ... End If
縮進(jìn)代碼會(huì )產(chǎn)生出更容易閱讀的代碼，如：
If ... Then If ... Then ... Else ... End If Else ... End If
為注釋和代碼建立最大的行長(cháng)度，以避免不得不滾動(dòng)源代碼編輯器，并且可以提供整齊的硬拷貝表示形式。
在大多數運算符之前和之后使用空格，這樣做時(shí)不會(huì )改變代碼的意圖。但是，C++ 中使用的指針表示法是一個(gè)例外。
使用空白為源代碼提供結構線(xiàn)索。這樣做會(huì )創(chuàng )建代碼“段”，有助于讀者理解軟件的邏輯分段。
當一行被分為幾行時(shí)，通過(guò)將串聯(lián)運算符放在每一行的末尾而不是開(kāi)頭，清楚地表示沒(méi)有后面的行是不完整的。
只要合適，每一行上放置的語(yǔ)句避免超過(guò)一條。例外是 C、C++、C# 或 JScript 中的循環(huán)，如 for (i = 0; i < 100; i++)。
編寫(xiě) HTML 時(shí)，建立標準的標記和屬性格式，如所有標記都大寫(xiě)或所有屬性都小寫(xiě)。另一種方法是，堅持 XHTML 規范以確保所有 HTML 文檔都有效。盡管在創(chuàng )建 Web 頁(yè)時(shí)需折中考慮文件大小，但應使用帶引號的屬性值和結束標記以方便維護。
編寫(xiě) SQL 語(yǔ)句時(shí)，對于關(guān)鍵字使用全部大寫(xiě)，對于數據庫元素（如表、列和視圖）使用大小寫(xiě)混合。
在物理文件之間在邏輯上劃分源代碼。
將每個(gè)主要的 SQL 子句放在不同的行上，這樣更容易閱讀和編輯語(yǔ)句，例如：
SELECT FirstName, LastName FROM Customers WHERE State = ‘WA‘
將大的復雜代碼節分為較小的、易于理解的模塊。
