當前位置:首頁 » 編程語言 » java開發規範文檔

java開發規範文檔

發布時間: 2022-08-13 02:31:51

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類標准代碼行數范圍大概是多少

以1000行為准,超過千行就要考慮類拆分了。
類的代碼行數沒有特定的行數限制規范。根據實際情況決定。
對於經常使用的java類,代碼行數應該盡可能的少,這樣能減少java類的載入時間,減少內存頻繁佔用和回收。如果類過大,java類載入會耗時並且佔用內存大。容易引起內存回收。

③ 這是最新的阿里java開發規范嗎

沒錯這個是最新

④ 自學Java開發技術注意事項

自學Java開發注意事項,Java作為一門語言,必然有他的語法規則。學習編程語言的關鍵之一就是學好語法規則,寫作合乎語法規則的語句,控制計算機完成各種任務。java語言在眾多開發者心目中就像是一把「利器」,同時它也是目前IT界流行的面向對象的編程語言。

1、自學Java技術多動手

學編程語言不僅僅是從理論上的學習,更重要的是要利用這門語言為你的思想服務。理解這門語言是首要的,但是要達到心領神會、融會貫通就必須勤動手,多去時間,多編一些例子。計算機科學是注重實踐的學科,成功的軟體開發人員無不經過大量的上機鍛煉,只有理論和實踐相結合才能真正掌握只是和技能。

2、自學Java技術多動腦

對於Java語言的學習,不僅僅是對語言本身的學習,更重要的是面向對象思想的簡歷過程,如果想把Java學習提升到一個更高的層次,Java私塾建議從一開始就用面向對象的思維方式去面對你所接觸的每件事。

3、自學Java技術多查API文檔

Java提供了大量的類以滿足網路化、多線程、面向對象的需要。這就是J2SEAPI,它是Java編程的基本方法,也是編程過程中所不斷利用的資源。Java的學習過程不僅僅是基本語法的學習,更多的是去學習和掌握它所提供的API類庫。對於所接觸到的類,方法,都去仔細去閱讀文檔的說明,再用自己編寫的實例去此時一下。

4、自學Java技術約束自己,規范編碼習慣

養成良好的編碼習慣對於一個程序員來講具有相當大的意義。一方面良好的編程習慣對於減少編碼過程中一些人為的錯誤能起到主動避免的作用;另一方面一段程序寫的好壞,不僅僅是功能上的實現,更主要的是可讀性,可維護性,沒有任何人願意去閱讀一段沒有順序,雜亂無章的代碼。建議大家在編碼的時候要時刻想到:如果這段代碼給別人看,別人是否看得懂,條理是否清楚。

5、自學Java技術用有意義的名字

名字,是一個標識,是一種有內涵的簡單表述。在編寫程序的過程中,為每個類、每個方法起一個有意義的名字。在程序閱讀的過程中,看到這個名字就可以知道她多完成的功能。

6、自學Java技術添加適量的注釋

注釋不僅僅是對程序邏輯處理的一種注釋,更多的是提高了程序的可讀性和可維護性。做為一個軟體產品,哪怕只是一個小小的功能的實現,其中不同的變數及方法可能很多,雖然在命名的過程中要使用有意義的名字,但也不能完全涵蓋變數及方法的功能及內涵,多為了提高程序的可讀性,添加一定的注釋是非常有必要的。合理的注釋不僅能起到美化程序的作用還能提高程序可讀性和維護性。

7、自學Java技術相信自己

相信自己包括兩方面,一是相信自己的能力,二是相信自己的答案。相信自己的能力就是要相信自己具有解決問題的能力。一個程序員的好壞並不是直接決定於是否能編寫出好的代碼,更重要的是能否自己去解決調試過程中遇到的任何問題,很少有一個程序員寫出的代碼一次成功,只有在不斷的調試,修正中才能編寫出真正的好代碼。調試、解決問題的過程就是自己學習提高的過程。對於不同的問題在不同的資料上可能有不同的答案,就像小馬過河一樣,不同的人可能有不同的答案,所以不要去盲目的相信任何人,要相信自己。

免責聲明:內容來源於公開網路,若涉及侵權聯系盡快刪除!

⑤ 誰有java開發規范類文檔!謝謝

你的qq是多少我把我的華為規范發你吧
java開發規范http://download.csdn.net/source/260572給你推薦個吧,沒有分留言我把我號借你
java編程規范http://download.csdn.net/source/254487這個更好推薦!

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

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

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

BTW:你是大學老師?著急評職稱?

⑦ java開發文檔怎麼寫

問了一下我在遠標教育的哥們,他說要做java開發文檔得做不少功夫,有需求規格說明書、詳細設計說明書、軟體功能規格說明書、資料庫設計說明書、編碼規范等。比較重要的是 軟體功能描述、資料庫設計、編碼規范,這樣,及時有人員流動的話,新人看了文檔,也能比較快的了解功能需求、資料庫設計、編碼規范,更快的上手項目。

⑧ java軟體開發的代碼規范

1、組織與風格
(1).關鍵詞和操作符之間加適當的空格。
(2).相對獨立的程序塊與塊之間加空行
(3).較長的語句、表達式等要分成多行書寫。
(4).劃分出的新行要進行適應的縮進,使排版整齊,語句可讀。
(5).長表達式要在低優先順序操作符處劃分新行,操作符放在新行之首。
(6).循環、判斷等語句中若有較長的表達式或語句,則要進行適應的劃分。
(7).若函數或過程中的參數較長,則要進行適當的劃分。
(8).不允許把多個短語句寫在一行中,即一行只寫一條語句。
(9).函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格。
註:如果大家有興趣可以到安安DIY創作室博客,有相關說明性的文章和解釋。
2、註解
Java 的語法與 C++ 及為相似,那麼,你知道 Java 的注釋有幾種嗎?是兩種?
// 注釋一行
/* ...... */ 注釋若干行
不完全對,除了以上兩種之外,還有第三種,文檔注釋:
/** ...... */ 注釋若干行,並寫入 javadoc 文檔
注釋要簡單明了。
String userName = null; //用戶名
邊寫代碼邊注釋,修改代碼同時修改相應的注釋,以保證注釋與代碼的一致性。
在必要的地方注釋,注釋量要適中。注釋的內容要清楚、明了,含義准確,防止注釋二義性。
保持注釋與其描述的代碼相鄰,即注釋的就近原則。
對代碼的注釋應放在其上方相鄰位置,不可放在下面。對數據結構的注釋應放在其上方相鄰位置,不可放在下面;對結構中的每個域的注釋應放在此域的右方;
同一結構中不同域的注釋要對齊。
變數、常量的注釋應放在其上方相鄰位置或右方。
全局變數要有較詳細的注釋,包括對其功能、取值范圍、哪些函數或過程存取它以及存取時注意事項等的說明。
在每個源文件的頭部要有必要的注釋信息,包括:文件名;版本號;作者;生成日期;模塊功能描述(如功能、主要演算法、內部各部分之間的關系、該文件與其它文件關系等);主要函數或過程清單及本文件歷史修改記錄等。
/**
* Copy Right Information : Neusoft IIT
* Project : eTrain
* JDK version used : jdk1.3.1
* Comments : config path
* Version : 1.01
* Modification history :2003.5.1
* Sr Date Modified By Why & What is modified
* 1. 2003.5.2 Kevin Gao new
**/
在每個函數或過程的前面要有必要的注釋信息,包括:函數或過程名稱;功能描述;輸入、輸出及返回值說明;調用關系及被調用關系說明等
/**
* Description :checkout 提款
* @param Hashtable cart info
* @param OrderBean order info
* @return String
*/
public String checkout(Hashtable htCart,
OrderBean orderBean)
throws Exception{
}
javadoc注釋標簽語法
@author 對類的說明 標明開發該類模塊的作者
@version 對類的說明 標明該類模塊的版本
@see 對類、屬性、方法的說明 參考轉向,也就是相關主題
@param 對方法的說明 對方法中某參數的說明
@return 對方法的說明 對方法返回值的說明
@exception 對方法的說明 對方法可能拋出的異常進行說明
3、命名規范
定義這個規范的目的是讓項目中所有的文檔都看起來像一個人寫的,增加可讀性,減少項目組中因為換人而帶來的損失。(這些規范並不是一定要絕對遵守,但是一定要讓程序有良好的可讀性)較短的單詞可通過去掉母音形成縮寫;要不然最後自己寫的代碼自己都看不懂了,那可不行。
較長的單詞可取單詞的頭幾發符的優先順序,並用括弧明確表達式的操作順序,避免使用默認優先順序。
使用匈牙利表示法
Package 的命名
Package 的名字應該都是由一個小寫單片語成。
package com.neu.util
Class 的命名
Class 的名字必須由大寫字母開頭而其他字母都小寫的單片語成,對於所有標識符,其中包含的所有單詞都應緊靠在一起,而且大寫中間單詞的首字母。
public class ThisAClassName{}
Class 變數的命名
變數的名字必須用一個小寫字母開頭。後面的單詞用大寫字母開頭
userName , thisAClassMethod
Static Final 變數的命名
static Final 變數的名字應該都大寫,並且指出完整含義。
/**
*DBConfig PATH
**/
public static final String
DB_CONFIG_FILE_PATH =com.neu.etrain.dbconfig;
參數的命名
參數的名字必須和變數的命名規范一致。
數組的命名
數組應該總是用下面的方式來命名:
byte[] buffer;
而不是:
byte buffer[];
方法的參數
使用有意義的參數命名,如果可能的話,使用和要賦值的欄位一樣的名字:
SetCounter(int size){
this.size = size;
}
4、文件樣式
所有的 Java(*.java) 文件都必須遵守如下的樣式規則:
版權信息
版權信息必須在 java 文件的開頭,比如:
/*
* Copyright ? 2000 Shanghai XXX Co. Ltd.
* All right reserved.
*/
其他不需要出現在 javadoc 的信息也可以包含在這里。
Package/Imports
package 行要在 import 行之前,import 中標準的包名要在本地的包名之前,而且按照字母
順序排列。如果 import 行中包含了同一個包中的不同子目錄,則應該用 * 來處理。
package hotlava.net.stats;
import java io.*;
import java.util.Observable;
import hotlava.util.Application;
這里 java。io.* 使用來代替InputStream and OutputStream 的。
Class
接下來的是類的注釋,一般是用來解釋類的。
/**
* A class representing a set of packet and byte counters
* It is observable to allow it to be watched, but only
* reports changes when the current set is complete
*/
接下來是類定義,包含了在不同的行的 extends 和 implements
public class CounterSet
extends Observable
implements Cloneable
Class Fields
接下來是類的成員變數:
/**
* Packet counters
*/
protected int[] packets;
public 的成員變數必須生成文檔(JavaDoc)。proceted、private和 package 定義的成
員變數如果名字含義明確的話,可以沒有注釋。
存取方法
接下來是類變數的存取的方法。它只是簡單的用來將類的變數賦值獲取值的話,可以簡單的
寫在一行上。
/**
* Get the counters
* @return an array containing the statistical data. This array has been
* freshly allocated and can be modified by the caller.
*/
public int[] getPackets() { return Array(packets, offset); }
public int[] getBytes() { return Array(bytes, offset); }
public int[] getPackets() { return packets; }
public void setPackets(int[] packets) { this.packets = packets; }
其它的方法不要寫在一行上
構造函數
接下來是構造函數,它應該用遞增的方式寫(比如:參數多的寫在後面)。
訪問類型 (public, private 等.) 和 任何 static, final 或 synchronized 應該在一行
中,並且方法和參數另寫一行,這樣可以使方法和參數更易讀。
public
CounterSet(int size){
this.size = size;
}
克隆方法
如果這個類是可以被克隆的,那麼下一步就是 clone 方法:
public
Object clone() {
try {
CounterSet obj = (CounterSet)super.clone();
obj.packets = (int[])packets.clone();
obj.size = size;
return obj;
}catch(CloneNotSupportedException e) {
throw new InternalError(Unexpected CloneNotSUpportedException: +
e.getMessage());
}
}
類方法
下面開始寫類的方法:
/**
* Set the packet counters
* (such as when restoring from a database)
*/
protected final
void setArray(int[] r1, int[] r2, int[] r3, int[] r4)
throws IllegalArgumentException
{
//
// Ensure the arrays are of equal size
//
if (r1.length != r2.length || r1.length != r3.length || r1.length != r4.length)
throw new IllegalArgumentException(Arrays must be of the same size);
System.array(r1, 0, r3, 0, r1.length);
System.array(r2, 0, r4, 0, r1.length);
}
toString 方法
無論如何,每一個類都應該定義 toString 方法:
public
String toString() {
String retval = CounterSet: ;
for (int i = 0; i < data.length(); i++) {
retval += data.bytes.toString();
retval += data.packets.toString();
}
return retval;
}
}
main 方法
如果main(String[]) 方法已經定義了, 那麼它應該寫在類的底部.
5、代碼可讀性
避免使用不易理解的數字,用有意義的標識來替代。
不要使用難懂的技巧性很高的語句。
源程序中關系較為緊密的代碼應盡可能相鄰。
6、代碼性能
在寫代碼的時候,從頭至尾都應該考慮性能問題。這不是說時間都應該浪費在優化代碼上,而是我們時刻應該提醒自己要注意代碼的效率。比如:如果沒有時間來實現一個高效的演算法,那麼我們應該在文檔中記錄下來,以便在以後有空的時候再來實現她。
不是所有的人都同意在寫代碼的時候應該優化性能這個觀點的,他們認為性能優化的問題應該在項目的後期再去考慮,也就是在程序的輪廓已經實現了以後。
不必要的對象構造
不要在循環中構造和釋放對象
使用 StringBuffer 對象
在處理 String 的時候要盡量使用 StringBuffer 類,StringBuffer 類是構成 String 類的基礎。
String 類將 StringBuffer 類封裝了起來,(以花費更多時間為代價)為開發人員提供了一個安全的介面。當我們在構造字元串的時候,我們應該用 StringBuffer 來實現大部分的工作,當工作完成後將 StringBuffer 對象再轉換為需要的 String 對象。比如:如果有一個字元串必須不斷地在其後添加許多字元來完成構造,那麼我們應該使用StringBuffer 對象和她的 append() 方法。如果我們用 String 對象代替StringBuffer 對象的話,會花費許多不必要的創建和釋放對象的 CPU 時間。大家可以來安安DIY創作室一起討論。
避免太多的使用 synchronized 關鍵字避免不必要的使用關鍵字 synchronized,應該在必要的時候再使用她,這是一個避免死鎖的好方法。
7、編程技巧
byte 數組轉換到 characters
為了將 byte 數組轉換到 characters,你可以這么做:
Hello world!.getBytes();
Utility 類
Utility 類(僅僅提供方法的類)應該被申明為抽象的來防止被繼承或被初始化。
初始化
下面的代碼是一種很好的初始化數組的方法:
objectArguments = new Object[] { arguments };
枚舉類型
JAVA 對枚舉的支持不好,但是下面的代碼是一種很有用的模板:
class Colour {
public static final Colour BLACK = new Colour(0, 0, 0);
public static final Colour RED = new Colour(0xFF, 0, 0);
public static final Colour GREEN = new Colour(0, 0xFF, 0);
public static final Colour BLUE = new Colour(0, 0, 0xFF);
public static final Colour WHITE = new Colour(0xFF, 0xFF, 0xFF);
}
這種技術實現了RED, GREEN, BLUE 等可以象其他語言的枚舉類型一樣使用的常量。
他們可以用 '==' 操作符來比較。
但是這樣使用有一個缺陷:如果一個用戶用這樣的方法來創建顏色 BLACK new Colour(0,0,0)
那麼這就是另外一個對象,'=='操作符就會產生錯誤。她的 equal() 方法仍然有效。由於這個原因,這個技術的缺陷最好註明在文檔中,或者只在自己的包中使用。
8、編寫格式
代碼樣式
代碼應該用 unix 的格式,而不是 windows 的(比如:回車變成回車+換行)
文檔化
必須用 javadoc 來為類生成文檔。不僅因為它是標准,這也是被各種 java 編譯器都認可的方法。使用 @author 標記是不被推薦的,因為代碼不應該是被個人擁有的。
縮進
縮進應該是每行2個空格. 不要在源文件中保存Tab字元. 在使用不同的源代碼管理工具時Tab字元將因為用戶設置的不同而擴展為不同的寬度.如果你使用 UltrEdit 作為你的 Java 源代碼編輯器的話,你可以通過如下操作來禁止保存Tab字元, 方法是通過 UltrEdit中先設定 Tab 使用的長度室2個空格,然後用 Format|Tabs to Spaces 菜單將 Tab 轉換為空格。
頁寬
頁寬應該設置為80字元. 源代碼一般不會超過這個寬度, 並導致無法完整顯示, 但這一設置也可以靈活調整. 在任何情況下, 超長的語句應該在一個逗號或者一個操作符後折行. 一條語句折行後, 應該比原來的語句再縮進2個字元.
{} 對
{} 中的語句應該單獨作為一行. 例如, 下面的第1行是錯誤的, 第2行是正確的:
if (i>0) { i ++ }; // 錯誤, { 和 } 在同一行
if (i>0) {
i ++
}; // 正確, { 單獨作為一行
} 語句永遠單獨作為一行.如果 } 語句應該縮進到與其相對應的 { 那一行相對齊的位置。
括弧
左括弧和後一個字元之間不應該出現空格, 同樣, 右括弧和前一個字元之間也不應該出現空格. 下面的例子說明括弧和空格的錯誤及正確使用:
CallProc( AParameter ); // 錯誤
CallProc(AParameter); // 正確
不要在語句中使用無意義的括弧. 括弧只應該為達到某種目的而出現在源代碼中。下面的例子說明錯誤和正確的用法:
if ((I) = 42) { // 錯誤 - 括弧毫無意義
if (I == 42) or (J == 42) then // 正確 - 的確需要括弧
9、代碼編譯
1.編寫代碼時要注意隨時保存,並定期備份,防止由於斷電、硬碟損壞等原因造成代碼丟失。
2.同一項目組內,最好使用相同的編輯器,並使用相同的設置選項。
3.合理地設計軟體系統目錄,方便開發人員使用。
4.打開編譯器的所有告警開關對程序進行編譯。
5.在同一項目組或產品組中,要統一編譯開關選項。
6.使用工具軟體(如Visual SourceSafe)對代碼版本進行維護。如果大家有不明白的可以到安安DIY創作室留言。
10、可移植性
Borland Jbulider 不喜歡 synchronized 這個關鍵字,如果你的斷點設在這些關鍵字的作用域內的話,調試的時候你會發現的斷點會到處亂跳,讓你不知所措。除非必須,盡量不要使用。
換行
如果需要換行的話,盡量用 println 來代替在字元串中使用 。
你不要這樣:
System.out.print(Hello,world! );
要這樣:
System.out.println(Hello,world!);
或者你構造一個帶換行符的字元串,至少要象這樣:
String newline = System.getProperty(line.separator);
System.out.println(Hello world + newline);
PrintStream
PrintStream 已經被不贊成(deprecated)使用,用 PrintWrite 來代替它。

⑨ java實戰開發entity規范命名不能加下劃線嗎

命名倒是都可以,不過在企業開發中,基本都是用駝峰命名,極少用下劃線方式。除了考慮它們本身的美觀度或識別度外,另一個是考慮對應生成的getter、setter的美觀度。還有就是Java官方的文檔基本也都是駝峰式命名,所以使用駝峰式看起來更統一一些。

⑩ Java項目開發標准

你可以看一個東西,叫做cmmi。
CMMI全稱是Capability Maturity Model Integration,即能力成熟度模型集成(也有稱為:軟體能力成熟度集成模型),是美國國防部的一個設想,1994年由美國國防部(United States Department of Defense)與卡內基-梅隆大學(Carnegie-Mellon University)下的軟體工程研究中心(Software Engineering Institute,SEISM)以及美國國防工業協會(National Defense Instrial Association)共同開發和研製的,他們計劃把現在所有現存實施的與即將被發展出來的各種能力成熟度模型,集成到一個框架中去,申請此認證的前提條件是該企業具有有效的軟體企業認定證書。
其目的是幫助軟體企業對軟體工程過程進行管理和改進,增強開發與改進能力,從而能按時地、不超預算地開發出高質量的軟體。其所依據的想法是:只要集中精力持續努力去建立有效的軟體工程過程的基礎結構,不斷進行管理的實踐和過程的改進,就可以克服軟體開發中的困難。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架,新的集成模型框架消除了各個模型的不一致性,減少了模型間的重復,增加透明度和理解,建立了一個自動的、可擴展的框架。因而能夠從總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。

CMMI 是現在來說最為規范的項目開發標准。一般上點規模的公司都起碼要過cmmi3級才行。

熱點內容
解壓到當前文件夾右鍵 發布:2024-04-26 03:57:08 瀏覽:979
html5android教程視頻下載 發布:2024-04-26 03:09:59 瀏覽:867
伺服器的描述是什麼 發布:2024-04-26 03:08:32 瀏覽:394
個人加密 發布:2024-04-26 03:01:23 瀏覽:521
linuxusbgadget 發布:2024-04-26 02:52:54 瀏覽:304
我的世界空島世界伺服器地址 發布:2024-04-26 01:39:08 瀏覽:248
尼爾機械紀元加密 發布:2024-04-26 01:37:11 瀏覽:868
在控制台輸出sql語句 發布:2024-04-26 01:08:12 瀏覽:432
動畫java 發布:2024-04-26 01:02:40 瀏覽:12
得力文件夾5302 發布:2024-04-26 00:21:32 瀏覽:91