Java 程序編碼規範

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

所有的程序開發手冊都包含了各種規則。一些習慣自由程序人員可能對這些規則很不適應，但是在多個開發人員共同寫作的情況下，這些規則是必需的。這不僅僅是爲了開發效率來考慮，而且也是爲了後期維護考慮。

命名規範
定義這個規範的目的是讓項目中所有的文檔都看起來像一個人寫的，增加可讀性，減少項目組中因爲換人而帶來的損失。（這些規範並不是一定要絕對遵守，但是一定要讓程序有良好的可讀性）

• Package 的命名
  Package 的名字應該都是由一個小寫單詞組成。

• Class 的命名
  Class 的名字必須由大寫字母開頭而其他字母都小寫的一個或多個單詞組成

• Class 變量的命名
  變量的名字必須用一個小寫字母開頭。後面的單詞用大寫字母開頭。

• Static Final 變量的命名
  Static Final 變量的名字應該都大寫，並且指出完整含義。

• 參數的命名
  輸入參數由in打頭，輸出參數由out打頭。名字必須和變量的命名規範一致。

• 數組的命名
  數組應該總是用下面的方式來命名：

• 而不是：

• 方法的參數
  使用有意義的參數命名，如果可能的話，使用和要賦值的字段一樣的名字加上in/out前綴：

Java 文件樣式
所有的 Java(*.java) 文件都必須遵守如下的樣式規則

• 版權信息
  版權信息必須在 java 文件的開頭，比如：

• 其他不需要出現在 javadoc 的信息也可以包含在這裏。

• Package/Imports
  package 行要在 import 行之前，import 中標準的包名要在本地的包名之前，而且按照字母順序排列。如果 import 行中包含了同一個包中的不同子目錄，則應該用 * 來處理。

• 這裏 java.io.* 是用來代替InputStream and OutputStream 的。

• Class
  接下來的是類的註釋，一般是用來解釋類的。

• 接下來是類定義，包含了在不同的行的 extends 和 implements

• Class Fields
  接下來是類的成員變量：

• public 的成員變量必須生成文檔（JavaDoc），如果說明比較短的話可以用/** */把說明寫在一行內。proceted、private和 package 定義的成員變量如果名字含義明確的話，可以沒有註釋。

• 存取方法
  接下來是類變量的存取的方法。它只是簡單的用來將類的變量賦值獲取值的話，可以簡單的寫在一行上。

• 其它的方法不要寫在一行上。

• 構造函數
  接下來是構造函數，它應該用遞增的方式寫（比如：參數多的寫在後面）。
  訪問類型 ("public", "private" 等.) 和 任何 "static", "final" 或 "synchronized" 應該在一行中，如果一行太長的話應該把方法和參數另寫一行，這樣可以使方法和參數更易讀。 關鍵字必須按照一定的次序書寫，如下所示：

• 克隆方法
  如果這個類是可以被克隆的，那麼下一步就是 clone 方法：

• 類方法
  下面開始寫類的方法（說明中最好要提供@param和@return的說明）：

• toString 方法
  無論如何，每一個類都應該定義 toString 方法：

 

• main 方法
  如果main(String[]) 方法已經定義了, 那麼它應該寫在類的底部.

代碼編寫格式

• 代碼樣式
  代碼應該用 unix 的格式，而不是 windows 的（比如：回車變成回車+換行）

• 文檔化
  必須書寫適用於javadoc理解的源代碼註釋，並用 javadoc 來爲類生成文檔。不僅因爲它是標準，這也是被各種 java 編譯器都認可的方法。

• 縮進
  請統一使用Tab字符進行代碼縮進排版,並把Tab的寬度設置爲4個字符；確保編輯器的“自動把Tab符轉化爲空格符”選項有效。否則一旦其他人的編輯器Tab字符寬度不一致時整個格式就亂掉了。

• 頁寬
  頁寬應該設置爲80字符，源代碼一般不會超過這個寬度，並導致無法完整顯示，但這一設置也可以靈活調整。在任何情況下，超長的語句應該在一個逗號或者一個操作符後折行，一條語句折行後，應該與原來的語句對齊。

• {} 對
  {} 中的語句應該單獨作爲一行. 例如, 下面的第1行是錯誤的, 第2行是正確的:

• } 語句應該縮進到與其相對應的 { 那一行相對齊的位置。即便只有一行語句也應該將其用{}包含起來，以便於以後往裏面添加新的語句。

• 括號
  左括號和後一個字符之間不應該出現空格, 同樣, 右括號和前一個字符之間也不應該出現空格. 下面的例子說明括號和空格的錯誤及正確使用:
  
  CallProc( AParameter ); // 錯誤
  CallProc(AParameter); // 正確
  
  不要在語句中使用無意義的括號. 括號只應該爲達到某種目的而出現在源代碼中。下面的例子說明錯誤和正確的用法:
  
  if (42 == (I)) { // 錯誤 - 括號毫無意義
  if ( (42 == I) || (42 == J) ) {// 正確 - 的確需要括號

• 操作符
  不管是邏輯操作符還是算術操作符，兩邊一定要加上空格符，而不是全都擠在一起，比如：
  
  int nA=a+v*c; // 錯誤 – 沒有空格
  inr nA = a + v * c; // 正確 - 需要空格

• 條件語句
  請比較以下兩種寫法：
  
  if(nType == -1) … …
  if(-1 == nType) … …
  
  使用第一種方法可能造成的情況是：當你不小心把==號寫成了=號的時候（這種情況時常發生），第一種寫法可能會導致你把代碼看上個幾百次也無法發現這個錯誤；而採用第二種寫法的則會在編譯階段就會由編譯器告訴你這個錯誤。因此在進行條件比較的時候，必須把常量數值放到==號的前面。另外，對於布爾值的比較，必須明確的寫明true 或者 false，比如：
  
  if(getFileType())  // 錯誤
  if(true == getFileType())  // 正確
  
  

程序編寫規範

• exit()
  exit 除了在 main 中可以被調用外，其他的地方不應該調用。因爲這樣做不給任何代碼代碼機會來截獲退出。一個類似後臺服務地程序不應該因爲某一個庫模塊決定了要退出就退出。

• 異常
  申明的錯誤應該拋出一個RuntimeException或者派生的異常。
  頂層的main()函數應該截獲所有的異常，並且打印（或者記錄在日誌中）在屏幕上。

• 垃圾收集
  JAVA使用成熟的後臺垃圾收集技術來代替引用計數。但是這樣會導致一個問題：你必須在使用完對象的實例以後進行清場工作。比如一個prel的程序員可能這麼寫：

• 除非輸出流一出作用域就關閉，非引用計數的程序語言，比如JAVA，是不能自動完成變量的清場工作的。必須象下面一樣寫：

• Clone
  下面是一種有用的方法：

• final 類
  絕對不要因爲性能的原因將類定義爲 final 的（除非程序的框架要求）
  如果一個類還沒有準備好被繼承，最好在類文檔中註明，而不要將她定義爲 final 的。這是因爲沒有人可以保證會不會由於什麼原因需要繼承她。

• 訪問類的成員變量
  大部分的類成員變量應該定義爲 protected 的來防止繼承類使用他們。
  注意，要用"int[] packets"，而不是"int packets[]"，後一種永遠也不要用。

 

• servlet的命名規則
  對於servlet在進行部署的時候，統一使用.svr的後綴名作爲servlet的訪問方式。 如下在web.xml中對mySomeAction這個servlet進行配置的時候，配置信息如下：

<servlet>

      <servlet-name>mySomeAction</servlet-name>

      <servlet-class>com.sportscn.mypackage.mySomeAction</servlet-class>

  </servlet>

  <servlet-mapping>

     <servlet-name>mySomeAction</servlet-name>

     <url-pattern>/mySomeAction.svr</url-pattern>

   </servlet-mapping>

編程技巧

• byte 數組轉換到 characters
  爲了將 byte 數組轉換到 characters，你可以這麼做：
  
  "Hello world!".getBytes();

• Utility 類
  Utility 類（僅僅提供方法的類）應該被申明爲抽象的來防止被繼承或被初始化。

• 初始化
  下面的代碼是一種很好的初始化數組的方法：
  
  objectArguments = new Object[] { arguments };

• 枚舉類型
  JAVA 對枚舉的支持不好，但是下面的代碼是一種很有用的模板：

 

• 這種技術實現了RED, GREEN, BLUE 等可以象其他語言的枚舉類型一樣使用的常量。 他們可以用 '==' 操作符來比較。
  但是這樣使用有一個缺陷：如果一個用戶用這樣的方法來創建顏色 BLACK
  
  new Colour(0,0,0)
  
  那麼這就是另外一個對象，'=='操作符就會產生錯誤。她的 equal() 方法仍然有效。由於這個原因，這個技術的缺陷最好註明在文檔中，或者只在自己的包中使用。

Swing

• 避免使用 AWT 組件
  • 混合使用 AWT 和 Swing 組件
    如果要將 AWT 組件和 Swing 組件混合起來使用的話，請小心使用。實際上，儘量不要將他們混合起來使用。

  • 滾動的 AWT 組件
    AWT 組件絕對不要用 JscrollPane 類來實現滾動。滾動 AWT 組件的時候一定要用 AWT ScrollPane 組件來實現。

  • 避免在 InternalFrame 組件中使用 AWT 組件
    儘量不要這麼做，要不然會出現不可預料的後果。

  • Z-Order 問題
    AWT 組件總是顯示在 Swing 組件之上。當使用包含 AWT 組件的 POP-UP 菜單的時候要小心，儘量不要這樣使用。

調試

• 調試在軟件開發中是一個很重要的部分，存在軟件生命週期的各個部分中。調試能夠用配置開、關是最基本的。
  
  很常用的一種調試方法就是用一個 PrintStream 類成員，在沒有定義調試流的時候就爲 null，類要定義一個 debug 方法來設置調試用的流。

性能

• 在寫代碼的時候，從頭至尾都應該考慮性能問題。這不是說時間都應該浪費在優化代碼上，而是我們時刻應該提醒自己要注意代碼的效率。比如：如果沒有時間來實現一個高效的算法，那麼我們應該在文檔中記錄下來，以便在以後有空的時候再來實現她。

• 不必要的對象構造
  • 不要在循環中構造和釋放對象

  • 使用 StringBuffer 對象
    在處理 String 的時候要儘量使用 StringBuffer 類，StringBuffer 類是構成 String 類的基礎。String 類將 StringBuffer 類封裝了起來，（以花費更多時間爲代價）爲開發人員提供了一個安全的接口。當我們在構造字符串的時候，我們應該用 StringBuffer 來實現大部分的工作，當工作完成後將 StringBuffer 對象再轉換爲需要的 String 對象。比如：如果有一個字符串必須不斷地在其後添加許多字符來完成構造，那麼我們應該使用 StringBuffer 對象和她的 append() 方法。如果我們用 String 對象代替 StringBuffer 對象的話，會花費許多不必要的創建和釋放對象的 CPU 時間。

• 避免太多的使用 synchronized 關鍵字
  避免不必要的使用關鍵字 synchronized，應該在必要的時候再使用她，這是一個避免死鎖的好方法。

可移植性
Borland Jbulider 不喜歡 synchronized 這個關鍵字，如果你的斷點設在這些關鍵字的作用域內的話，調試的時候你會發現的斷點會到處亂跳，讓你不知所措。除非必須，儘量不要使用。

• 換行
  如果需要換行的話，儘量用 println 來代替在字符串中使用"/n"。
  你不要這樣：
  
  System.out.print("Hello,world!/n");
  
  要這樣：
  
  System.out.println("Hello,world!");
  
  或者你構造一個帶換行符的字符串，至少要象這樣：
  
  String newline = System.getProperty("line.separator");
  System.out.println("Hello world" + newline);

• PrintStream
  PrintStream 已經被不贊成（deprecated）使用，用 PrintWriter 來代替她。