分析一套源代碼的代碼規範和風格並討論如何改進優化代碼

1.結合工程實踐選題相關的一套源代碼，根據其編程語言或項目特色，分析其在源代碼目錄結構、文件名/類名/函數名/變量名等命名、接口定義規範和單元測試組織形式等方面的作法和特色；

　　主要分析了elasticsearch：Open Source, Distributed, RESTful Search Engine，文件結構：

 

 

 　　這款軟件主要是按照不一樣的功能劃分了不一樣的Java包名，每一個包裏面的類都分別完成這個軟件的某個模塊。

2.列舉哪些作法符合代碼規範和風格通常要求；

　　這款軟件有一些專門的單元測試，每個類和一些主要的public方法都會進行註釋，方便了之後代碼的更新和維護。

3.總結同類編程語言或項目在代碼規範和風格的通常要求。

　　這裏主要總結一些Java的編程規範:

　　1.對於具備特殊轉義序列的任何字符(\b, \t, \n, \f, \r, ", '及\)，咱們使用它的轉義序列，而不是相應的八進制(好比\012)或Unicode(好比\u000a)轉義;對於剩餘的非ASCII字符，是使用實際的Unicode字符(好比∞)，仍是使用等價的Unicode轉義符(好比\u221e)，取決於哪一個能讓代碼更易於閱讀和理解.

　　2.一個源文件包含(按順序地)：許可證或版權信息(若有須要)，package語句，import語句，一個頂級類(只有一個)，以上每一個部分之間用一個空行隔開。

　　3.當一個類有多個構造函數，或是多個同名方法，這些函數/方法應該按順序出如今一塊兒，中間不要放進其它函數/方法。

　　4.一個空的塊狀結構裏什麼也不包含，大括號能夠簡潔地寫成{}，不須要換行。例外：若是它是一個多塊語句的一部分(if/else 或 try/catch/finally) ，即便大括號內沒內容，右大括號也要換行。

　　5.不要在一個代碼塊的開頭把局部變量一次性都聲明瞭(這是c語言的作法)，而是在第一次須要使用它時才聲明。 局部變量在聲明時最好就進行初始化，或者聲明後儘快進行初始化。

　　6.在一個switch塊內，每一個語句組要麼經過break, continue, return或拋出異常來終止，要麼經過一條註釋來講明程序將繼續執行到下一個語句組， 任何能表達這個意思的註釋都是OK的(典型的是用// fall through)。這個特殊的註釋並不須要在最後一個語句組(通常是default)中出現。

　　7.註解緊跟在文檔塊後面，應用於類、方法和構造函數，一個註解獨佔一行。這些換行不屬於自動換行，所以縮進級別不變。

　　8.塊註釋與其周圍的代碼在同一縮進級別。它們能夠是/* ... */風格，也能夠是// ...風格。對於多行的/* ... */註釋，後續行必須從*開始， 而且與前一行的*對齊。

　　9.只要是合法的，就把@Override註解給用上。

　　10.標準的Javadoc標記按如下順序出現：@param, @return, @throws, @deprecated, 前面這4種標記若是出現，描述都不能爲空。 當描述沒法在一行中容納，連續行須要至少再縮進4個空格。