java規范

Ⅰ java語言規范

你可以在電腦上下載個java幫助文檔 有什麼問題了可以去幫助文檔上去查查

Ⅱ java編程規范

不需要！在逗號後面加不加空格都無所謂

Ⅲ java的規定

JAVA規范

1. Package 的命名
Package 的名字應該都是由小寫單片語成。 package com.neu.util

2. Class 的命名
Class 的名字必須由大寫字母開頭而其他字母都小寫的單片語成,對於所有標識符，其中包含的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。
public class ThisAClassName{}

3. Class 變數的命名
變數的名字必須用一個小寫字母開頭。後面的單詞用大寫字母開頭,如 userName , thisAClassMethod

4. Static Final 變數的命名

static Final 變數的名字應該都大寫，並且指出完整含義。

/**
*DBConfig PATH
**/
public static final String
DB_CONFIG_FILE_PATH ="com.neu.etrain.dbconfig";

5. 數組的命名

數組應該總是用下面的方式來命名：
byte[ ] buffer; 而不是： byte buffer[];

6, 方法的參數

使用有意義的參數命名，如果可能的話，使用和要賦值的欄位一樣的名字：

SetCounter(int size){

this.size = size;
}

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

if (i>0) { i ++ }; // 錯誤, { 和 } 在同一行

if (i>0) {
i ++
}; // 正確, { 單獨作為一行

} 語句永遠單獨作為一行.

} 語句應該縮進到與其相對應的 { 那一行相對齊的位置。

8.括弧
左括弧和後一個字元之間不應該出現空格, 同樣, 右括弧和前一個字元之間也不應該出現空格. 下面的例子說明括弧和空格的錯誤及正確使用:

CallProc( AParameter ); // 錯誤
CallProc(AParameter); // 正確

9, Java的語法與 C++ 及為相似，那麼，你知道 Java 的注釋有幾種嗎？是兩種？

// 注釋一行

/* ...... */ 注釋若干行

不完全對，除了以上兩種之外，還有第三種，文檔注釋：

/** ...... */ 注釋若干行，並寫入 javadoc 文檔

Java代碼規范
--注釋

@author LEI

@version 1.10 2005-09-01

1 注釋文檔的格式
注釋文檔將用來生成HTML格式的代碼報告，所以注釋文檔必須書寫在類、域、構造函數、方法、定義之前。注釋文檔由兩部分組成——描述、塊標記。

例如：

/**

* The doGet method of the servlet.

* This method is called when a form has its tag value method equals to get.

*

* @param request

* the request send by the client to the server

* @param response

* the response send by the server to the client

* @throws ServletException

* if an error occurred

* @throws IOException

* if an error occurred

*/

public void doGet (HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

doPost(request, response);

}

前兩行為描述，描述完畢後，由@符號起頭為塊標記注視。

2 注釋的種類
2.1 文件頭注釋
文件頭注釋以 /*開始，以*/結束，需要註明該文件創建時間，文件名，命名空間信息。

例如：

/*

* Created on 2005-7-2

* /

2.2 類、介面注釋
類、介面的注釋採用 /** … */，描述部分用來書寫該類的作用或者相關信息，塊標記部分必須註明作者和版本。

例如：

/**Title: XXXX DRIVER 3.0
*Description: XXXX DRIVER 3.0
*Copyright: Copyright (c) 2003
*Company:XXXX有限公司
*
* @author Java Development Group
* @version 3.0
*/

例如：

/**
* A class representing a window on the screen.
* For example:
*
* Window win = new Window(parent);
* win.show();
*
*
* @author Sami Shaio
* @version %I%, %G%
* @see java.awt.BaseWindow
* @see java.awt.Button
*/

class Window extends BaseWindow {

...

}

2.3 構造函數注釋
構造函數注釋採用 /** … */，描述部分註明構造函數的作用，不一定有塊標記部分。

例如：

/**

* 默認構造函數

*/

有例如：

/**

* 帶參數構造函數,初始化模式名,名稱和數據源類型

*

* @param schema

* Ref 模式名

* @param name

* Ref 名稱

* @param type

* byVal 數據源類型

*/

2.4 域注釋
域注釋可以出現在注釋文檔裡面，也可以不出現在注釋文檔裡面。用/** … */的域注釋將會被認為是注釋文檔熱出現在最終生成的HTML報告裡面，而使用/* … */的注釋會被忽略。

例如：

/* 由於triger和表用一個DMSource，所以要區分和表的遷移成功標記 */

boolean isTrigerSuccess = false;

又例如：

/** 由於triger和表用一個DMSource，所以要區分和表的遷移成功標記 */

boolean isTrigerSuccess = false;

再例如：

/**

* The X-coordinate of the component.

*

* @see #getLocation()

*/

int x = 1263732;

2.5 方法注釋
方法注釋採用 /** … */，描述部分註明方法的功能，塊標記部分註明方法的參數，返回值，異常等信息。例如：

/**

* 設置是否有外碼約束

*

* @param conn

* Connection 與資料庫的連接

*/

Ⅳ java的都有哪些規范

規范有點多，你仔細看看，若不懂的可以問，但是我相信隨著時間的推移，你自己以後也會慢慢領悟的：

JAVA代碼規范：

(1) 類名首字母應該大寫。欄位、方法以及對象（句柄）的首字母應小寫。對於所有標識符，其中包含的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。例如：
ThisIsAClassName
thisIsMethodOrFieldName
若在定義中出現了常數初始化字元，則大寫static final基本類型標識符中的所有字母。這樣便可標志出它們屬於編譯期的常數。
Java包（Package）屬於一種特殊情況：它們全都是小寫字母，即便中間的單詞亦是如此。對於域名擴展名稱，如com，org，net或者e等，全部都應小寫（這也是Java 1.1和Java 1.2的區別之一）。

(2) 為了常規用途而創建一個類時，請採取"經典形式"，並包含對下述元素的定義：

equals()
hashCode()
toString()
clone()（implement Cloneable）
implement Serializable

(3) 對於自己創建的每一個類，都考慮置入一個main()，其中包含了用於測試那個類的代碼。為使用一個項目中的類，我們沒必要刪除測試代碼。若進行了任何形式的改動，可方便地返回測試。這些代碼也可作為如何使用類的一個示例使用。

(4) 應將方法設計成簡要的、功能性單元，用它描述和實現一個不連續的類介面部分。理想情況下，方法應簡明扼要。若長度很大，可考慮通過某種方式將其分割成較短的幾個方法。這樣做也便於類內代碼的重復使用（有些時候，方法必須非常大，但它們仍應只做同樣的一件事情）。

(5) 設計一個類時，請設身處地為客戶程序員考慮一下（類的使用方法應該是非常明確的）。然後，再設身處地為管理代碼的人考慮一下（預計有可能進行哪些形式的修改，想想用什麼方法可把它們變得更簡單）。
(6) 使類盡可能短小精悍，而且只解決一個特定的問題。下面是對類設計的一些建議：
■一個復雜的開關語句：考慮採用"多形"機制
■數量眾多的方法涉及到類型差別極大的操作：考慮用幾個類來分別實現
■許多成員變數在特徵上有很大的差別：考慮使用幾個類

(7) 讓一切東西都盡可能地"私有"--private。可使庫的某一部分"公共化"（一個方法、類或者一個欄位等等），就永遠不能把它拿出。若強行拿出，就可能破壞其他人現有的代碼，使他們不得不重新編寫和設計。若只公布自己必須公布的，就可放心大膽地改變其他任何東西。在多線程環境中，隱私是特別重要的一個因素--只有private欄位才能在非同步使用的情況下受到保護。

(8) 謹惕"巨大對象綜合症"。對一些習慣於順序編程思維、且初涉OOP領域的新手，往往喜歡先寫一個順序執行的程序，再把它嵌入一個或兩個巨大的對象里。根據編程原理，對象表達的應該是應用程序的概念，而非應用程序本身。

(9) 若不得已進行一些不太雅觀的編程，至少應該把那些代碼置於一個類的內部。

(10) 任何時候只要發現類與類之間結合得非常緊密，就需要考慮是否採用內部類，從而改善編碼及維護工作（參見第14章14.1.2小節的"用內部類改進代碼"）。

(11) 盡可能細致地加上注釋，並用javadoc注釋文檔語法生成自己的程序文檔。

(12) 避免使用"魔術數字"，這些數字很難與代碼很好地配合。如以後需要修改它，無疑會成為一場噩夢，因為根本不知道"100"到底是指"數組大小"還是"其他全然不同的東西"。所以，我們應創建一個常數，並為其使用具有說服力的描述性名稱，並在整個程序中都採用常數標識符。這樣可使程序更易理解以及更易維護。

(13) 涉及構建器和異常的時候，通常希望重新丟棄在構建器中捕獲的任何異常--如果它造成了那個對象的創建失敗。這樣一來，調用者就不會以為那個對象已正確地創建，從而盲目地繼續。

(14) 當客戶程序員用完對象以後，若你的類要求進行任何清除工作，可考慮將清除代碼置於一個良好定義的方法里，採用類似於cleanup()這樣的名字，明確表明自己的用途。除此以外，可在類內放置一個boolean（布爾）標記，指出對象是否已被清除。在類的finalize()方法里，請確定對象已被清除，並已丟棄了從RuntimeException繼承的一個類（如果還沒有的話），從而指出一個編程錯誤。在採取象這樣的方案之前，請確定finalize()能夠在自己的系統中工作（可能需要調用System.runFinalizersOnExit(true)，從而確保這一行為）。

(15) 在一個特定的作用域內，若一個對象必須清除（非由垃圾收集機制處理），請採用下述方法：初始化對象；若成功，則立即進入一個含有finally從句的try塊，開始清除工作。

(16) 若在初始化過程中需要覆蓋（取消）finalize()，請記住調用super.finalize()（若Object屬於我們的直接超類，則無此必要）。在對finalize()進行覆蓋的過程中，對super.finalize()的調用應屬於最後一個行動，而不應是第一個行動，這樣可確保在需要基礎類組件的時候它們依然有效。

(17) 創建大小固定的對象集合時，請將它們傳輸至一個數組（若准備從一個方法里返回這個集合，更應如此操作）。這樣一來，我們就可享受到數組在編譯期進行類型檢查的好處。此外，為使用它們，數組的接收者也許並不需要將對象"造型"到數組里。

(18) 盡量使用interfaces，不要使用abstract類。若已知某樣東西准備成為一個基礎類，那麼第一個選擇應是將其變成一個interface（介面）。只有在不得不使用方法定義或者成員變數的時候，才需要將其變成一個abstract（抽象）類。介面主要描述了客戶希望做什麼事情，而一個類則致力於（或允許）具體的實施細節。

(19) 在構建器內部，只進行那些將對象設為正確狀態所需的工作。盡可能地避免調用其他方法，因為那些方法可能被其他人覆蓋或取消，從而在構建過程中產生不可預知的結果（參見第7章的詳細說明）。

(20) 對象不應只是簡單地容納一些數據；它們的行為也應得到良好的定義。

(21) 在現成類的基礎上創建新類時，請首先選擇"新建"或"創作"。只有自己的設計要求必須繼承時，才應考慮這方面的問題。若在本來允許新建的場合使用了繼承，則整個設計會變得沒有必要地復雜。

(22) 用繼承及方法覆蓋來表示行為間的差異，而用欄位表示狀態間的區別。一個非常極端的例子是通過對不同類的繼承來表示顏色，這是絕對應該避免的：應直接使用一個"顏色"欄位。

(23) 為避免編程時遇到麻煩，請保證在自己類路徑指到的任何地方，每個名字都僅對應一個類。否則，編譯器可能先找到同名的另一個類，並報告出錯消息。若懷疑自己碰到了類路徑問題，請試試在類路徑的每一個起點，搜索一下同名的.class文件。

(24) 在Java 1.1 AWT中使用事件"適配器"時，特別容易碰到一個陷阱。若覆蓋了某個適配器方法，同時拼寫方法沒有特別講究，最後的結果就是新添加一個方法，而不是覆蓋現成方法。然而，由於這樣做是完全合法的，所以不會從編譯器或運行期系統獲得任何出錯提示--只不過代碼的工作就變得不正常了。

(25) 用合理的設計方案消除"偽功能"。也就是說，假若只需要創建類的一個對象，就不要提前限制自己使用應用程序，並加上一條"只生成其中一個"注釋。請考慮將其封裝成一個"獨生子"的形式。若在主程序里有大量散亂的代碼，用於創建自己的對象，請考慮採納一種創造性的方案，將些代碼封裝起來。

(26) 警惕"分析癱瘓"。請記住，無論如何都要提前了解整個項目的狀況，再去考察其中的細節。由於把握了全局，可快速認識自己未知的一些因素，防止在考察細節的時候陷入"死邏輯"中。

(27) 警惕"過早優化"。首先讓它運行起來，再考慮變得更快--但只有在自己必須這樣做、而且經證實在某部分代碼中的確存在一個性能瓶頸的時候，才應進行優化。除非用專門的工具分析瓶頸，否則很有可能是在浪費自己的時間。性能提升的隱含代價是自己的代碼變得難於理解，而且難於維護。

(28) 請記住，閱讀代碼的時間比寫代碼的時間多得多。思路清晰的設計可獲得易於理解的程序，但注釋、細致的解釋以及一些示例往往具有不可估量的價值。無論對你自己，還是對後來的人，它們都是相當重要的。如對此仍有懷疑，那麼請試想自己試圖從聯機Java文檔里找出有用信息時碰到的挫折，這樣或許能將你說服。

(29) 如認為自己已進行了良好的分析、設計或者實施，那麼請稍微更換一下思維角度。試試邀請一些外來人士--並不一定是專家，但可以是來自本公司其他部門的人。請他們用完全新鮮的眼光考察你的工作，看看是否能找出你一度熟視無睹的問題。採取這種方式，往往能在最適合修改的階段找出一些關鍵性的問題，避免產品發行後再解決問題而造成的金錢及精力方面的損失。

(30) 良好的設計能帶來最大的回報。簡言之，對於一個特定的問題，通常會花較長的時間才能找到一種最恰當的解決方案。但一旦找到了正確的方法，以後的工作就輕松多了，再也不用經歷數小時、數天或者數月的痛苦掙扎。我們的努力工作會帶來最大的回報（甚至無可估量）。而且由於自己傾注了大量心血，最終獲得一個出色的設計方案，成功的快感也是令人心動的。堅持****草草完工的誘惑--那樣做往往得不償失

Ⅳ JAVA 函數的規范寫法

java裡面一般不叫函數，叫方法；
一般:
作用域+修飾詞+返回類型（無返回就void）+方法名(//參數列表,也可以不寫，根據實際情況){//方法實現}
例如：
public static int fun(int i){
return i;
}
這是一個公有的靜態方法，該方法返回一個整形數據，參數是一個int型

Ⅵ Java 的官方語言規范與標准

當然有，名字就叫 Java 語言規范啊 The Java Language Specification，sun 官方的，HTML 和 pdf 都有
http://java.sun.com/docs/books/jls/
API 裡面就有好多處引用
你連這都不知道，顯然沒好好看 API，還跑到網路這種地方來問？初學者水平還寫書？

你這樣浪費別人的時間和金錢，是純粹的謀財害命
不是我說的，是列寧說的
你還是先寫點讀書筆記吧

BTW：你是大學老師？著急評職稱？

Ⅶ java與規范

簡單的理解為是用java語言實現的一種設計思想, 在javase的基礎上加入了一些jdbc，EJB，Servlet，JSP，XML等技術的全面支持，其最終目標是成為一個支持企業級應用開發的體系結構，簡化企業解決方案的開發，部署和管理等復雜問題
javaee是通過jar包發布，你可以理解成框架，比如jdbc，只是定義了規范，具體實現是由資料庫廠商的java程序員基於javaee的規范實現的

Ⅷ java 注釋規范

/**
*方法功能描述
*
*@param參數說明
*@author作者
*@return返回格式
*@exception異常
*/

Ⅸ java編程規范！！！

名稱 Java語言編碼規范(Java Code Conventions)
簡介 本文檔講述了Java語言的編碼規范，較之陳世忠先生《c++編碼規范》的浩繁詳盡，此文當屬短小精悍了。而其中所列之各項條款，從編碼風格，到注意事項，不單只Java，對於其他語言，也都很有借鑒意義。因為簡短，所以易記，大家不妨將此作為handbook，常備案頭，逐一對驗。
1 介紹
1.1 為什麼要有編碼規范
1.2 版權聲明
2 文件名
2.1 文件後綴
2.2 常用文件名
3 文件組織
3.1 Java源文件
3.1.1 開頭注釋
3.1.2 包和引入語句
3.1.3 類和介面聲明
4 縮進排版
4.1 行長度
4.2 換行
5 注釋
5.1 實現注釋的格式
5.1.1 塊注釋
5.1.2 單行注釋
5.1.3 尾端注釋
5.1.4 行末注釋
5.2 文擋注釋
6 聲明
6.1 每行聲明變數的數量
6.2 初始化
6.3 布局
6.4 類和介面的聲明
7 語句
7.1 簡單語句
7.2 復合語句
7.3 返回語句
7.4 if，if-else，if else-if else語句
7.5 for語句
7.6 while語句
7.7 do-while語句
7.8 switch語句
7.9 try-catch語句
8 空白
8.1 空行
8.2 空格
9 命名規范
10 編程慣例
10.1 提供對實例以及類變數的訪問控制
10.2 引用類變數和類方法
10.3 常量
10.4 變數賦值
10.5 其它慣例
10.5.1 圓括弧
10.5.2 返回值
10.5.3 條件運算符"?"前的表達式"?"前的表達式
10.5.4 特殊注釋
11 代碼範例
11.1 Java源文件範例

1 介紹(Introction)

1.1 為什麼要有編碼規范(Why Have Code Conventions)

編碼規范對於程序員而言尤為重要，有以下幾個原因：

- 一個軟體的生命周期中，80%的花費在於維護
- 幾乎沒有任何一個軟體，在其整個生命周期中，均由最初的開發人員來維護
- 編碼規范可以改善軟體的可讀性，可以讓程序員盡快而徹底地理解新的代碼
- 如果你將源碼作為產品發布，就需要確任它是否被很好的打包並且清晰無誤，一如你已構建的其它任何產品

為了執行規范，每個軟體開發人員必須一致遵守編碼規范。每個人。

1.2 版權聲明(Acknowledgments)

本文檔反映的是Sun MicroSystems公司，Java語言規范中的編碼標准部分。主要貢獻者包括：Peter King，Patrick Naughton，Mike DeMoney，Jonni Kanerva，Kathy Walrath以及Scott Hommel。

本文檔現由Scott Hommel維護，有關評論意見請發至[email protected]

2 文件名(File Names)

這部分列出了常用的文件名及其後綴。

2.1 文件後綴(File Suffixes)

Java程序使用下列文件後綴：

文件類別 文件後綴
Java源文件 .java
Java位元組碼文件 .class

2.2 常用文件名(Common File Names)

常用的文件名包括：

文件名 用途
GNUmakefile makefiles的首選文件名。我們採用gnumake來創建（build）軟體。
README 概述特定目錄下所含內容的文件的首選文件名

3 文件組織(File Organization)

一個文件由被空行分割而成的段落以及標識每個段落的可選注釋共同組成。超過2000行的程序難以閱讀，應該盡量避免。"Java源文件範例"提供了一個布局合理的Java程序範例。

3.1 Java源文件(Java Source Files)

每個Java源文件都包含一個單一的公共類或介面。若私有類和介面與一個公共類相關聯，可以將它們和公共類放入同一個源文件。公共類必須是這個文件中的第一個類或介面。

Java源文件還遵循以下規則：

- 開頭注釋（參見"開頭注釋"）
- 包和引入語句（參見"包和引入語句"）
- 類和介面聲明（參見"類和介面聲明"）

3.1.1 開頭注釋(Beginning Comments)

所有的源文件都應該在開頭有一個C語言風格的注釋，其中列出類名、版本信息、日期和版權聲明：

/*
* Classname
*
* Version information
*
* Date
*
* Copyright notice
*/

3.1.2 包和引入語句(Package and Import Statements)

在多數Java源文件中，第一個非注釋行是包語句。在它之後可以跟引入語句。例如：

package java.awt;

import java.awt.peer.CanvasPeer;

3.1.3 類和介面聲明(Class and Interface Declarations)

下表描述了類和介面聲明的各個部分以及它們出現的先後次序。參見"Java源文件範例"中一個包含注釋的例子。

類/介面聲明的各部分 註解
1 類/介面文檔注釋(/**……*/) 該注釋中所需包含的信息，參見"文檔注釋"
2 類或介面的聲明
3 類/介面實現的注釋(/*……*/)如果有必要的話 該注釋應包含任何有關整個類或介面的信息，而這些信息又不適合作為類/介面文檔注釋。
4 類的(靜態)變數 首先是類的公共變數，隨後是保護變數，再後是包一級別的變數(沒有訪問修飾符，access modifier)，最後是私有變數。
5 實例變數 首先是公共級別的，隨後是保護級別的，再後是包一級別的(沒有訪問修飾符)，最後是私有級別的。
6 構造器
7 方法 這些方法應該按功能，而非作用域或訪問許可權，分組。例如，一個私有的類方法可以置於兩個公有的實例方法之間。其目的是為了更便於閱讀和理解代碼。

4 縮進排版(Indentation)

4個空格常被作為縮進排版的一個單位。縮進的確切解釋並未詳細指定(空格 vs. 製表符)。一個製表符等於8個空格(而非4個)。

4.1 行長度(Line Length)

盡量避免一行的長度超過80個字元，因為很多終端和工具不能很好處理之。

注意：用於文檔中的例子應該使用更短的行長，長度一般不超過70個字元。

4.2 換行(Wrapping Lines)

當一個表達式無法容納在一行內時，可以依據如下一般規則斷開之：

- 在一個逗號後面斷開
- 在一個操作符前面斷開
- 寧可選擇較高級別(higher-level)的斷開，而非較低級別(lower-level)的斷開
- 新的一行應該與上一行同一級別表達式的開頭處對齊
- 如果以上規則導致你的代碼混亂或者使你的代碼都堆擠在右邊，那就代之以縮進8個空格。

以下是斷開方法調用的一些例子：

someMethod(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);

var = someMethod1(longExpression1,
someMethod2(longExpression2,
longExpression3));

以下是兩個斷開算術表達式的例子。前者更好，因為斷開處位於括弧表達式的外邊，這是個較高級別的斷開。

longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6; //PREFFER

longName1 = longName2 * (longName3 + longName4
- longName5) + 4 * longname6; //AVOID

以下是兩個縮進方法聲明的例子。前者是常規情形。後者若使用常規的縮進方式將會使第二行和第三行移得很靠右，所以代之以縮進8個空格

//CONVENTIONAL INDENTATION
someMethod(int anArg, Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}

//INDENT 8 SPACES TO AVOID VERY DEEP INDENTS
private static synchronized horkingLongMethodName(int anArg,
Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}

if語句的換行通常使用8個空格的規則，因為常規縮進(4個空格)會使語句體看起來比較費勁。比如：

//DON』T USE THIS INDENTATION
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) { //BAD WRAPS
doSomethingAboutIt(); //MAKE THIS LINE EASY TO MISS
}

//USE THIS INDENTATION INSTEAD
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}

//OR USE THIS
if ((condition1 && condition2) || (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}

這里有三種可行的方法用於處理三元運算表達式：

alpha = (aLongBooleanExpression) ? beta : gamma;

alpha = (aLongBooleanExpression) ? beta
: gamma;

alpha = (aLongBooleanExpression)
? beta
: gamma;

5 注釋(Comments)

Java程序有兩類注釋：實現注釋(implementation comments)和文檔注釋(document comments)。實現注釋是那些在C++中見過的，使用/*...*/和//界定的注釋。文檔注釋(被稱為"doc comments")是Java獨有的，並由/**...*/界定。文檔注釋可以通過javadoc工具轉換成HTML文件。

實現注釋用以注釋代碼或者實現細節。文檔注釋從實現自由(implementation-free)的角度描述代碼的規范。它可以被那些手頭沒有源碼的開發人員讀懂。

注釋應被用來給出代碼的總括，並提供代碼自身沒有提供的附加信息。注釋應該僅包含與閱讀和理解程序有關的信息。例如，相應的包如何被建立或位於哪個目錄下之類的信息不應包括在注釋中。

在注釋里，對設計決策中重要的或者不是顯而易見的地方進行說明是可以的，但應避免提供代碼中己清晰表達出來的重復信息。多餘的的注釋很容易過時。通常應避免那些代碼更新就可能過時的注釋。

注意：頻繁的注釋有時反映出代碼的低質量。當你覺得被迫要加註釋的時候，考慮一下重寫代碼使其更清晰。

注釋不應寫在用星號或其他字元畫出來的大框里。注釋不應包括諸如製表符和回退符之類的特殊字元。

5.1 實現注釋的格式(Implementation Comment Formats)

程序可以有4種實現注釋的風格：塊(block)、單行(single-line)、尾端(trailing)和行末(end-of-line)。

5.1.1 塊注釋(Block Comments)

塊注釋通常用於提供對文件，方法，數據結構和演算法的描述。塊注釋被置於每個文件的開始處以及每個方法之前。它們也可以被用於其他地方，比如方法內部。在功能和方法內部的塊注釋應該和它們所描述的代碼具有一樣的縮進格式。

塊注釋之首應該有一個空行，用於把塊注釋和代碼分割開來，比如：

/*
* Here is a block comment.
*/

塊注釋可以以/*-開頭，這樣indent(1)就可以將之識別為一個代碼塊的開始，而不會重排它。

/*-
* Here is a block comment with some very special
* formatting that I want indent(1) to ignore.
*
* one
* two
* three
*/

注意：如果你不使用indent(1)，就不必在代碼中使用/*-，或為他人可能對你的代碼運行indent(1)作讓步。

參見"文檔注釋"

5.1.2 單行注釋(Single-Line Comments)

短注釋可以顯示在一行內，並與其後的代碼具有一樣的縮進層級。如果一個注釋不能在一行內寫完，就該採用塊注釋(參見"塊注釋")。單行注釋之前應該有一個空行。以下是一個Java代碼中單行注釋的例子：

if (condition) {

/* Handle the condition. */
...
}

5.1.3 尾端注釋(Trailing Comments)

極短的注釋可以與它們所要描述的代碼位於同一行，但是應該有足夠的空白來分開代碼和注釋。若有多個短注釋出現於大段代碼中，它們應該具有相同的縮進。

以下是一個Java代碼中尾端注釋的例子：

if (a == 2) {
return TRUE; /* special case */
} else {
return isPrime(a); /* works only for odd a */
}

5.1.4 行末注釋(End-Of-Line Comments)

注釋界定符"//"，可以注釋掉整行或者一行中的一部分。它一般不用於連續多行的注釋文本；然而，它可以用來注釋掉連續多行的代碼段。以下是所有三種風格的例子：

if (foo > 1) {

// Do a double-flip.
...
}
else {
return false; // Explain why here.
}

//if (bar > 1) {
//
// // Do a triple-flip.
// ...
//}
//else {
// return false;
//}

5.2 文檔注釋(Documentation Comments)

注意：此處描述的注釋格式之範例，參見"Java源文件範例"

若想了解更多，參見"How to Write Doc Comments for Javadoc"，其中包含了有關文檔注釋標記的信息(@return, @param, @see)：

http://java.sun.com/javadoc/writingdoccomments/index.html

若想了解更多有關文檔注釋和javadoc的詳細資料，參見javadoc的主頁：

http://java.sun.com/javadoc/index.html

文檔注釋描述Java的類、介面、構造器，方法，以及欄位(field)。每個文檔注釋都會被置於注釋定界符/**...*/之中，一個注釋對應一個類、介面或成員。該注釋應位於聲明之前：

/**
* The Example class provides ...
*/
public class Example { ...

注意頂層(top-level)的類和介面是不縮進的，而其成員是縮進的。描述類和介面的文檔注釋的第一行(/**)不需縮進；隨後的文檔注釋每行都縮進1格(使星號縱向對齊)。成員，包括構造函數在內，其文檔注釋的第一行縮進4格，隨後每行都縮進5格。

若你想給出有關類、介面、變數或方法的信息，而這些信息又不適合寫在文檔中，則可使用實現塊注釋(見5.1.1)或緊跟在聲明後面的單行注釋(見5.1.2)。例如，有關一個類實現的細節，應放入緊跟在類聲明後面的實現塊注釋中，而不是放在文檔注釋中。

文檔注釋不能放在一個方法或構造器的定義塊中，因為Java會將位於文檔注釋之後的第一個聲明與其相關聯。

6 聲明(Declarations)

6.1 每行聲明變數的數量(Number Per Line)

推薦一行一個聲明，因為這樣以利於寫注釋。亦即，

int level; // indentation level
int size; // size of table

要優於，

int level, size;

不要將不同類型變數的聲明放在同一行，例如：

int foo, fooarray[]; //WRONG!

注意：上面的例子中，在類型和標識符之間放了一個空格，另一種被允許的替代方式是使用製表符：

int level; // indentation level
int size; // size of table
Object currentEntry; // currently selected table entry

6.2 初始化(Initialization)

盡量在聲明局部變數的同時初始化。唯一不這么做的理由是變數的初始值依賴於某些先前發生的計算。

6.3 布局(Placement)

只在代碼塊的開始處聲明變數。（一個塊是指任何被包含在大括弧"{"和"}"中間的代碼。）不要在首次用到該變數時才聲明之。這會把注意力不集中的程序員搞糊塗，同時會妨礙代碼在該作用域內的可移植性。

void myMethod() {
int int1 = 0; // beginning of method block

if (condition) {
int int2 = 0; // beginning of "if" block
...
}
}

該規則的一個例外是for循環的索引變數

for (int i = 0; i < maxLoops; i++) { ... }

避免聲明的局部變數覆蓋上一級聲明的變數。例如，不要在內部代碼塊中聲明相同的變數名：

int count;
...
myMethod() {
if (condition) {
int count = 0; // AVOID!
...
}
...
}

6.4 類和介面的聲明(Class and Interface Declarations)

當編寫類和介面是，應該遵守以下格式規則：

- 在方法名與其參數列表之前的左括弧"("間不要有空格
- 左大括弧"{"位於聲明語句同行的末尾
- 右大括弧"}"另起一行，與相應的聲明語句對齊，除非是一個空語句，"}"應緊跟在"{"之後

class Sample extends Object {
int ivar1;
int ivar2;

Sample(int i, int j) {
ivar1 = i;
ivar2 = j;
}

int emptyMethod() {}

...
}

- 方法與方法之間以空行分隔

7 語句(Statements)

7.1 簡單語句(Simple Statements)

每行至多包含一條語句，例如：

argv++; // Correct
argc--; // Correct
argv++; argc--; // AVOID!

7.2 復合語句(Compound Statements)

復合語句是包含在大括弧中的語句序列，形如"{ 語句 }"。例如下面各段。

- 被括其中的語句應該較之復合語句縮進一個層次
- 左大括弧"{"應位於復合語句起始行的行尾；右大括弧"}"應另起一行並與復合語句首行對齊。
- 大括弧可以被用於所有語句，包括單個語句，只要這些語句是諸如if-else或for控制結構的一部分。這樣便於添加語句而無需擔心由於忘了加括弧而引入bug。

7.3 返回語句(return Statements)

一個帶返回值的return語句不使用小括弧"()"，除非它們以某種方式使返回值更為顯見。例如：

return;

return myDisk.size();

return (size ? size : defaultSize);

7.4 if，if-else，if else-if else語句(if, if-else, if else-if else Statements)

if-else語句應該具有如下格式：

if (condition) {
statements;
}

if (condition) {
statements;
} else {
statements;
}

if (condition) {
statements;
} else if (condition) {
statements;
} else{
statements;
}

注意：if語句總是用"{"和"}"括起來，避免使用如下容易引起錯誤的格式：

if (condition) //AVOID! THIS OMITS THE BRACES {}!
statement;

7.5 for語句(for Statements)

一個for語句應該具有如下格式：

for (initialization; condition; update) {
statements;
}

一個空的for語句(所有工作都在初始化，條件判斷，更新子句中完成）應該具有如下格式：

for (initialization; condition; update);

當在for語句的初始化或更新子句中使用逗號時，避免因使用三個以上變數，而導致復雜度提高。若需要，可以在for循環之前(為初始化子句)或for循環末尾(為更新子句)使用單獨的語句。

7.6 while語句(while Statements)

一個while語句應該具有如下格式

while (condition) {
statements;
}

一個空的while語句應該具有如下格式：

while (condition);

7.7 do-while語句(do-while Statements)

一個do-while語句應該具有如下格式：

do {
statements;
} while (condition);

7.8 switch語句(switch Statements)

一個switch語句應該具有如下格式：

switch (condition) {
case ABC:
statements;
/* falls through */
case DEF:
statements;
break;

case XYZ:
statements;
break;

default:
statements;
break;
}

每當一個case順著往下執行時(因為沒有break語句)，通常應在break語句的位置添加註釋。上面的示例代碼中就包含注釋/* falls through */。

7.9 try-catch語句(try-catch Statements)

一個try-catch語句應該具有如下格式：

try {
statements;
} catch (ExceptionClass e) {
statements;
}

一個try-catch語句後面也可能跟著一個finally語句，不論try代碼塊是否順利執行完，它都會被執行。

try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}

8 空白(White Space)

8.1 空行(Blank Lines)

空行將邏輯相關的代碼段分隔開，以提高可讀性。

下列情況應該總是使用兩個空行：

- 一個源文件的兩個片段(section)之間
- 類聲明和介面聲明之間

下列情況應該總是使用一個空行：

- 兩個方法之間
- 方法內的局部變數和方法的第一條語句之間
- 塊注釋（參見"5.1.1"）或單行注釋（參見"5.1.2"）之前
- 一個方法內的兩個邏輯段之間，用以提高可讀性

8.2 空格(Blank Spaces)

下列情況應該使用空格：

- 一個緊跟著括弧的關鍵字應該被空格分開，例如：

while (true) {
...
}

注意：空格不應該置於方法名與其左括弧之間。這將有助於區分關鍵字和方法調用。
- 空白應該位於參數列表中逗號的後面
- 所有的二元運算符，除了"."，應該使用空格將之與操作數分開。一元操作符和操作數之間不因該加空格，比如：負號("-")、自增("++")和自減("--")。例如：
a += c + d;
a = (a + b) / (c * d);

while (d++ = s++) {
n++;
}
printSize("size is " + foo + "\n");

- for語句中的表達式應該被空格分開，例如：
for (expr1; expr2; expr3)

- 強制轉型後應該跟一個空格，例如：
myMethod((byte) aNum, (Object) x);
myMethod((int) (cp + 5), ((int) (i + 3)) + 1);

9 命名規范(Naming Conventions)

命名規范使程序更易讀，從而更易於理解。它們也可以提供一些有關標識符功能的信息，以助於理解代碼，例如，不論它是一個常量，包，還是類。

標識符類型 命名規則 例子
包(Packages) 一個唯一包名的前綴總是全部小寫的ASCII字母並且是一個頂級域名，通常是com，e，gov，mil，net，org，或1981年ISO 3166標准所指定的標識國家的英文雙字元代碼。包名的後續部分根據不同機構各自內部的命名規范而不盡相同。這類命名規范可能以特定目錄名的組成來區分部門(department)，項目(project)，機器(machine)，或注冊名(login names)。 com.sun.eng
com.apple.quicktime.v2
e.cmu.cs.bovik.cheese
類(Classes) 命名規則：類名是個一名詞，採用大小寫混合的方式，每個單詞的首字母大寫。盡量使你的類名簡潔而富於描述。使用完整單詞，避免縮寫詞(除非該縮寫詞被更廣泛使用，像URL，HTML) class Raster;
class ImageSprite;
介面(Interfaces) 命名規則：大小寫規則與類名相似 interface RasterDelegate;
interface Storing;
方法(Methods) 方法名是一個動詞，採用大小寫混合的方式，第一個單詞的首字母小寫，其後單詞的首字母大寫。 run();
runFast();
getBackground();
變數(Variables) 除了變數名外，所有實例，包括類，類常量，均採用大小寫混合的方式，第一個單詞的首字母小寫，其後單詞的首字母大寫。變數名不應以下劃線或美元符號開頭，盡管這在語法上是允許的。
變數名應簡短且富於描述。變數名的選用應該易於記憶，即，能夠指出其用途。盡量避免單個字元的變數名，除非是一次性的臨時變數。臨時變數通常被取名為i，j，k，m和n，它們一般用於整型；c，d，e，它們一般用於字元型。 char c;
int i;
float myWidth;
實例變數(Instance Variables) 大小寫規則和變數名相似，除了前面需要一個下劃線 int _employeeId;
String _name;
Customer _customer;
常量(Constants) 類常量和ANSI常量的聲明，應該全部大寫，單詞間用下劃線隔開。(盡量避免ANSI常量，容易引起錯誤) static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;

10 編程慣例(Programming Practices)

10.1 提供對實例以及類變數的訪問控制(Providing Access to Instance and Class Variables)

若沒有足夠理由，不要把實例或類變數聲明為公有。通常，實例變數無需顯式的設置(set)和獲取(gotten)，通常這作為方法調用的邊緣效應 (side effect)而產生。

一個具有公有實例變數的恰當例子，是類僅作為數據結構，沒有行為。亦即，若你要使用一個結構(struct)而非一個類(如果java支持結構的話)，那麼把類的實例變數聲明為公有是合適的。

Ⅹ JAVA編碼規范

(1) 類名首字母應該大寫。欄位、方法以及對象（句柄）的首字母應小寫。對於所有標識符，其中包含的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。例如：
ThisIsAClassName
thisIsMethodOrFieldName
若在定義中出現了常數初始化字元，則大寫static final基本類型標識符中的所有字母。這樣便可標志出它們屬於編譯期的常數。
Java包（Package）屬於一種特殊情況：它們全都是小寫字母，即便中間的單詞亦是如此。對於域名擴展名稱，如com，org，net或者e等，全部都應小寫（這也是Java 1.1和Java 1.2的區別之一）。
(2) 為了常規用途而創建一個類時，請採取"經典形式"，並包含對下述元素的定義：
equals()
hashCode()
toString()
clone()（implement Cloneable）
implement Serializable
(3) 對於自己創建的每一個類，都考慮置入一個main()，其中包含了用於測試那個類的代碼。為使用一個項目中的類，我們沒必要刪除測試代碼。若進行了任何形式的改動，可方便地返回測試。這些代碼也可作為如何使用類的一個示例使用。
(4) 應將方法設計成簡要的、功能性單元，用它描述和實現一個不連續的類介面部分。理想情況下，方法應簡明扼要。若長度很大，可考慮通過某種方式將其分割成較短的幾個方法。這樣做也便於類內代碼的重復使用（有些時候，方法必須非常大，但它們仍應只做同樣的一件事情）。
(5) 設計一個類時，請設身處地為客戶程序員考慮一下（類的使用方法應該是非常明確的）。然後，再設身處地為管理代碼的人考慮一下（預計有可能進行哪些形式的修改，想想用什麼方法可把它們變得更簡單）。
(6) 使類盡可能短小精悍，而且只解決一個特定的問題。下面是對類設計的一些建議：
一個復雜的開關語句：考慮採用"多形"機制
數量眾多的方法涉及到類型差別極大的操作：考慮用幾個類來分別實現
許多成員變數在特徵上有很大的差別：考慮使用幾個類
(7) 讓一切東西都盡可能地"私有"--private。可使庫的某一部分"公共化"（一個方法、類或者一個欄位等等），就永遠不能把它拿出。若強行拿出，就可能破壞其他人現有的代碼，使他們不得不重新編寫和設計。若只公布自己必須公布的，就可放心大膽地改變其他任何東西。在多線程環境中，隱私是特別重要的一個因素--只有private欄位才能在非同步使用的情況下受到保護。
(8) 謹惕"巨大對象綜合症"。對一些習慣於順序編程思維、且初涉OOP領域的新手，往往喜歡先寫一個順序執行的程序，再把它嵌入一個或兩個巨大的對象里。根據編程原理，對象表達的應該是應用程序的概念，而非應用程序本身。
(9) 若不得已進行一些不太雅觀的編程，至少應該把那些代碼置於一個類的內部。
(10) 任何時候只要發現類與類之間結合得非常緊密，就需要考慮是否採用內部類，從而改善編碼及維護工作（參見第14章14.1.2小節的"用內部類改進代碼"）。
(11) 盡可能細致地加上注釋，並用javadoc注釋文檔語法生成自己的程序文檔。
(12) 避免使用"魔術數字"，這些數字很難與代碼很好地配合。如以後需要修改它，無疑會成為一場噩夢，因為根本不知道"100"到底是指"數組大小"還是"其他全然不同的東西"。所以，我們應創建一個常數，並為其使用具有說服力的描述性名稱，並在整個程序中都採用常數標識符。這樣可使程序更易理解以及更易維護。
(13) 涉及構建器和異常的時候，通常希望重新丟棄在構建器中捕獲的任何異常--如果它造成了那個對象的創建失敗。這樣一來，調用者就不會以為那個對象已正確地創建，從而盲目地繼續。
(14) 客戶程序員用完對象以後，若你的類要求進行任何清除工作，可考慮將清除代碼置於一個良好定義的方法里，採用類似於cleanup()這樣的名字，明確表明自己的用途。除此以外，可在類內放置一個boolean（布爾）標記，指出對象是否已被清除。在類的finalize()方法里，請確定對象已被清除，並已丟棄了從RuntimeException繼承的一個類（如果還沒有的話），從而指出一個編程錯誤。在採取象這樣的方案之前，請確定finalize()能夠在自己的系統中工作（可能需要調用System.runFinalizersOnExit(true)，從而確保這一行為）。
(15) 在一個特定的作用域內，若一個對象必須清除（非由垃圾收集機制處理），請採用下述方法：初始化對象；若成功，則立即進入一個含有finally從句的try塊，開始清除工作。
(16) 若在初始化過程中需要覆蓋（取消）finalize()，請記住調用super.finalize()（若Object屬於我們的直接超類，則無此必要）。在對finalize()進行覆蓋的過程中，對super.finalize()的調用應屬於最後一個行動，而不應是第一個行動，這樣可確保在需要基礎類組件的時候它們依然有效。
(17) 創建大小固定的對象集合時，請將它們傳輸至一個數組（若准備從一個方法里返回這個集合，更應如此操作）。這樣一來，我們就可享受到數組在編譯期進行類型檢查的好處。此外，為使用它們，數組的接收者也許並不需要將對象"造型"到數組里。
(18) 盡量使用interfaces，不要使用abstract類。若已知某樣東西准備成為一個基礎類，那麼第一個選擇應是將其變成一個interface（介面）。只有在不得不使用方法定義或者成員變數的時候，才需要將其變成一個abstract（抽象）類。介面主要描述了客戶希望做什麼事情，而一個類則致力於（或允許）具體的實施細節。
(19) 在構建器內部，只進行那些將對象設為正確狀態所需的工作。盡可能地避免調用其他方法，因為那些方法可能被其他人覆蓋或取消，從而在構建過程中產生不可預知的結果（參見第7章的詳細說明）。
(20) 對象不應只是簡單地容納一些數據；它們的行為也應得到良好的定義。
(21) 在現成類的基礎上創建新類時，請首先選擇"新建"或"創作"。只有自己的設計要求必須繼承時，才應考慮這方面的問題。若在本來允許新建的場合使用了繼承，則整個設計會變得沒有必要地復雜。
(22) 用繼承及方法覆蓋來表示行為間的差異，而用欄位表示狀態間的區別。一個非常極端的例子是通過對不同類的繼承來表示顏色，這是絕對應該避免的：應直接使用一個"顏色"欄位。
(23) 為避免編程時遇到麻煩，請保證在自己類路徑指到的任何地方，每個名字都僅對應一個類。否則，編譯器可能先找到同名的另一個類，並報告出錯消息。若懷疑自己碰到了類路徑問題，請試試在類路徑的每一個起點，搜索一下同名的.class文件。
(24) 在Java 1.1 AWT中使用事件"適配器"時，特別容易碰到一個陷阱。若覆蓋了某個適配器方法，同時拼寫方法沒有特別講究，最後的結果就是新添加一個方法，而不是覆蓋現成方法。然而，由於這樣做是完全合法的，所以不會從編譯器或運行期系統獲得任何出錯提示--只不過代碼的工作就變得不正常了。
(25) 用合理的設計方案消除"偽功能"。也就是說，假若只需要創建類的一個對象，就不要提前限制自己使用應用程序，並加上一條"只生成其中一個"注釋。請考慮將其封裝成一個"獨生子"的形式。若在主程序里有大量散亂的代碼，用於創建自己的對象，請考慮採納一種創造性的方案，將些代碼封裝起來。
(26) 警惕"分析癱瘓"。請記住，無論如何都要提前了解整個項目的狀況，再去考察其中的細節。由於把握了全局，可快速認識自己未知的一些因素，防止在考察細節的時候陷入"死邏輯"中。
(27) 警惕"過早優化"。首先讓它運行起來，再考慮變得更快--但只有在自己必須這樣做、而且經證實在某部分代碼中的確存在一個性能瓶頸的時候，才應進行優化。除非用專門的工具分析瓶頸，否則很有可能是在浪費自己的時間。性能提升的隱含代價是自己的代碼變得難於理解，而且難於維護。
(28) 請記住，閱讀代碼的時間比寫代碼的時間多得多。思路清晰的設計可獲得易於理解的程序，但注釋、細致的解釋以及一些示例往往具有不可估量的價值。無論對你自己，還是對後來的人，它們都是相當重要的。如對此仍有懷疑，那麼請試想自己試圖從聯機Java文檔里找出有用信息時碰到的挫折，這樣或許能將你說服。
(29) 如認為自己已進行了良好的分析、設計或者實施，那麼請稍微更換一下思維角度。試試邀請一些外來人士--並不一定是專家，但可以是來自本公司其他部門的人。請他們用完全新鮮的眼光考察你的工作，看看是否能找出你一度熟視無睹的問題。採取這種方式，往往能在最適合修改的階段找出一些關鍵性的問題，避免產品發行後再解決問題而造成的金錢及精力方面的損失。
(30) 良好的設計能帶來最大的回報。簡言之，對於一個特定的問題，通常會花較長的時間才能找到一種最恰當的解決方案。但一旦找到了正確的方法，以後的工作就輕松多了，再也不用經歷數小時、數天或者數月的痛苦掙扎。我們的努力工作會帶來最大的回報（甚至無可估量）。而且由於自己傾注了大量心血，最終獲得一個出色的設計方案，成功的快感也是令人心動的。堅持抵制草草完工的誘惑－－那樣做往往得不償失。