java項目開發規範文檔,java開發文檔編寫規範

本文目錄一覽：

• 1、Java項目開發標準
• 2、一套完整的JAVA項目包括哪些部分？
• 3、java 項目需求文檔要怎麼寫？
• 4、java軟件開發的代碼規範
• 5、如何書寫Java項目的開發文檔
• 6、北大青鳥java培訓：Java編程開發規範及其技巧？

Java項目開發標準

你可以看一個東西，叫做cmmi。

CMMI全稱是Capability Maturity Model Integration，即能力成熟度模型集成（也有稱為：軟件能力成熟度集成模型），是美國國防部的一個設想，1994年由美國國防部（United States Department of Defense）與卡內基-梅隆大學（Carnegie-Mellon University）下的軟件工程研究中心（Software Engineering Institute，SEISM）以及美國國防工業協會（National Defense Industrial Association）共同開發和研製的，他們計劃把現在所有現存實施的與即將被發展出來的各種能力成熟度模型，集成到一個框架中去，申請此認證的前提條件是該企業具有有效的軟件企業認定證書。

其目的是幫助軟件企業對軟件工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。其所依據的想法是：只要集中精力持續努力去建立有效的軟件工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟件開發中的困難。CMMI為改進一個組織的各種過程提供了一個單一的集成化框架，新的集成模型框架消除了各個模型的不一致性，減少了模型間的重複，增加透明度和理解，建立了一個自動的、可擴展的框架。因而能夠從總體上改進組織的質量和效率。CMMI主要關注點就是成本效益、明確重點、過程集中和靈活性四個方面。

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

一套完整的JAVA項目包括哪些部分？

1、項目啟動

1）、項目組成立（公司成員、客戶成員）

2）、制定項目預期目標

3）、制定項目計劃周期

4）、建立好項目組成員溝通機制2、需求調研

1）、創建調研計劃、協調調研時間

2）、收集客戶資料，獲取客戶需求

所有的資料都需要保留一份，資料中存疑的需要及時詢問

3）、編寫需求文檔

重點描述出客戶的業務流程和性能要求。

採用Word、Excel、Rose等形式。

4）、需求變更記錄

5）、確定開發環境和運行環境

6）、擴展性要求

7）、與舊系統的接駁要求。

8）、估算出項目工作量本階段需要一套需求管理系統來進行需求的管理。 本階段的需求文檔也是用戶測試的依據。3、系統設計/詳細設計

一個系統可以分為基礎平台和應用模塊兩部分。

1）、選擇基礎平台，無論是採用第三方平台還是自行開發平台，都需要深入了解，查看是否符合要求。

2）、應用模塊設計（針對業務流程）

3）、中間件的採用或自行開發，需要深入了解。

4）、用戶界面的設計

如果用戶界面設計完畢並確認，即可初步寫出用戶使用手冊、管理員使用手冊。

5）、變更記錄本階段的系統設計是集成測試的依據。4、程序開發

創建開發任務計劃表、開發計劃日程表

1）、優先編寫測試用例

2）、按照編碼規範編寫代碼

3）、按照文檔注釋規範注釋

以上形成開發文檔。 本階段需要一套版本管理系統。 本階段的測試用例也是單元測試的依據。

如果能做到，最好每日構建。5、測試

本階段需要一套Bug管理系統，形成需求、設計、開發、測試互動。1）、編寫測試計劃和測試方案

2）、功能測試

單元測試、集成測試

3）、性能測試

集成測試、壓力測試如果能做到，最好能進行自動化測試。

如果能做到，做分析統計工作。最後形成測試報告。6、試用、培訓、維護

本階段需要解決：

1）、解決異地修改和公司修改的同步問題。

2）、用戶測試中的Bug修改問題，按照級別分為

a）、程序Bug

b）、設計變更

c）、需求變更

盡量按照a b c的順序來進行修改，盡量避免b、c級的修改。最後形成安裝手冊、維護記錄。

java 項目需求文檔要怎麼寫？

對於產品經理來說，產品需求文檔（PRD文檔）是工作的核心產出。一份嚴謹、優秀的產品需求文檔能夠給項目的其他人員，包括設計師，開發工程師，測試工程師，運營人員等帶來很大的幫助。但對於產品經理來說，撰寫一份完整的產品需求文檔往往需要花費相當多的時間和精力。

今天我們一起來看看，如何提升產品需求文檔的撰寫效率。

為什麼要寫產品需求文檔?

對於稍微大一點的產品開發團隊來說，產品經理未必能向所有團隊成員準確傳達產品開發需求，這時就需要一份完整的產品需求文檔供項目參與人員閱讀。

首先，產品經理可以根據項目的階段運營目標提出合理需求，通過PRD文檔闡述產品整體設計需求背景，設計思路，功能範圍，交互邏輯，頁面細節及其他信息。

其次，團隊的相關人員可以快速獲取自己需要的信息，節省反覆溝通的時間成本，更好地開展工作。

最後，產品需求文檔也是一個產品項目投入開發前的重要附件之一。團隊領導可以根據產品需求文檔清晰了解為什麼需要開發這樣一款產品。項目的其他相關方也可以隨時參閱需求文檔，了解項目的基本信息。

總的來說，產品需求文檔有三個核心作用：

傳達產品開發需求；

保證團隊成員溝通順暢；

制定產品質量控制標準。

產品需求文檔的在項目中的重要性已經不言而喻。那麼對於產品經理來說，有哪些技巧可以更好地完成產品需求文檔的撰寫呢？

產品需求文檔包含哪些內容？

通過下圖，我們可以簡單了解產品需求文檔需要呈現的基本內容。

請點擊輸入圖片描述

請點擊輸入圖片描述

1.產品概述

產品需求文檔的第一部分，首先需要對整個項目的研發背景及整體規划進行說明，讓閱讀者可以快速理解需求背景和產品定位。其次是對產品需求文檔本身進行闡述，在每一次修訂後都需要進行記錄，方便閱讀者了解產品需求文檔的修訂更新。這一部分主要包括以下內容：

項目概述

詞彙表

文檔修訂歷史

版本說明等

2.功能範圍

這一部分需結合用戶、業務規則及市場環境，對產品的用戶和市場需求進行分析梳理，找出差異性和優勢，制定業務流程和需求清單。可通過業務邏輯圖、流程圖、產品結構圖等圖表，讓產品邏輯和功能以最簡單的方式陳列出來，團隊成員可根據這一部分了解用戶信息、行為信息等，也有助於對產品進行進一步的理解。

3.功能詳情和原型

首先是列舉功能總表，將產品功能進行逐條梳理，每一條功能都能對應前面的產品目標。

其次是功能詳情展示，通過Mockplus等原型工具快速繪製原型，配合關鍵部分的批註說明，詳細描述業務模塊的展示、交互和數據邏輯，以供開發人員查看和理解。

4.全局說明

這一部分包括設計規範、數據統計、通用規則說明等信息，方便設計師和開發人員查看產品細節信息。

5. 測試需求

產品一般在正式上線前都有BETA版本或者內測版本，產品經理需要定製測試產品的功能或者性能。

6.非功能性需求

非功能需求為用戶常規操作產品時的極端情況，涉及很多內容，包括產品性能、安全性、可靠性、拓展性等方面。

7. 產品運營和市場分析

完成產品開發並不是終點，產品的最終目的是要贏得市場。產品上線後如何運營？建議的推廣策略是什麼？產品經理和運營人員該如何協作？等等問題。

產品需求文檔撰寫技巧

如何高效完成產品需求文檔的撰寫？我們可以從以下四個方面展開說明：

理清文檔結構

詳盡敘述每一個細節

語義明確，沒有歧義

搭配原型圖或設計稿進行說明

1.理清文檔結構

一份產品需求文檔的內容往往多而複雜，因此，產品經理在撰寫產品需求文檔時，必須理清文檔的結構，才能提升產品需求文檔的可讀性，讓閱讀者可以快速了解文檔的思路和查閱重要信息。

將一份產品需求文檔看做一個產品，首先需要梳理出它的結構，如上文中所呈現的文檔內容，然後再按順序進行撰寫，這樣才能寫出結構清晰，層次分明的產品需求文檔。

2.詳盡敘述每一個細節

當我們站在產品經理的角度思考問題時，往往會出現這樣的誤區：產品的這一功能模塊邏輯非常簡單，業內常見，開發人員也一定能懂，不用再進行單獨說明。

產品經理對於產品的功能及邏輯往往非常了解，但如果從開發或測試人員的角度來看，往往對於許多產品的細節和邏輯關係都不太了解。因此產品經理在撰寫產品需求文檔時，一定要做到事無巨細。不僅需要詳盡敘述頁面邏輯、交互邏輯、數據邏輯等所有細節，還需要從開發、測試等角度檢查是否有遺漏或錯誤，才能保證後續開發工作有條不紊。

3.語義明確，沒有歧義

在撰寫產品需求文檔時，要做到語義明確，不能出現讓閱讀者產生歧義的詞彙或語句，如：大概、可能、似乎等詞語。另一方面，對於產品定義的表述方式，必須做到全文統一。比如在撰寫一份APP的產品需求文檔時，前文寫了“首頁輪播圖”，後文就不能再使用“首頁Banner”、“橫幅”等名稱。

4.搭配原型圖或設計稿進行說明

產品需求文檔往往包含大量文字描述，團隊其他成員在閱讀某些功能細節時，往往無法完全理解文字內容。此時如果使用原型圖或設計稿進行說明，就可以補充文字內容很難描述的信息，幫助閱讀者快速理解產品功能和內在邏輯。因此產品經理在撰寫產品需求文檔時，需要配合原型圖或設計稿進行說明。

一款產品的原型圖或設計稿通常會進行反覆修改，產品需求文檔必須同步更新，才能讓閱讀者及時了解到項目的最新動態。但如果每修改一次原型圖或設計稿，產品經理都必須手動去替換文檔中的配圖內容，那效率就太低了！其實，使用高效的產品需求文檔撰寫神器即可解決這一難題。

產品需求文檔撰寫神器

隨着產品開發流程的不斷發展，Office等傳統辦公軟件已無法滿足產品文檔的撰寫需求。今天為大家推薦的，是一款專門面向產品經理的文檔工具——摹客：網頁鏈接。除了上述圖文同步的難題外，摹客還能解決審閱溝通、版本管理等產品需求文檔的寫作困境，讓產品經理可以更高效地創建專業的產品文檔。一起來看看~

1.富文本撰寫，充分表達產品需求

摹客全新的富文本在線寫作模式，符合產品經理日常編輯習慣，可以快速完成文檔撰寫。撰寫內容自動保存，可隨時查看歷史版本，方便對比修改。此外，產品經理也可以直接上傳本地產品文檔，會自動解析目錄，並生成文檔樹，方便查閱。

請點擊輸入圖片描述

2.與原型圖、設計稿深度結合，相互說明論證

產品經理在撰寫產品需求文檔時可插入設計稿，當對設計稿進行了更新修改，可在文檔中設置內容同步，無需重複插入。另外，團隊成員在設計稿上打點評論時，也可以引用文檔進行說明，讓團隊成員可以一目了然地查看相關信息。

請點擊輸入圖片描述

3.實時審閱，高效溝通

文檔編輯完成後可以通過鏈接一鍵分享給團隊成員，團隊成員可選中文字增加評論，對文檔進行在線審閱，清晰表達項目意見，實現產品開發團隊的高效溝通。

請點擊輸入圖片描述

請點擊輸入圖片描述

4.追蹤修改記錄，備份歷史版本

通常，產品需求文檔的寫作不會一步到位，往往會根據團隊成員的評審意見進行反覆修改，因此會產生大量的迭代版本，對於產品經理來說，如何管理產品需求文檔的歷史版本，是一個很大的難題。在摹客

撰寫產品文檔，每一次修改都可以自動生成歷史版本，可以隨時跳轉查看和恢復，管理便捷。

請點擊輸入圖片描述

請點擊輸入圖片描述

5.在線預覽、分享更便捷

在摹客中在線撰寫或上傳的產品需求文檔，可通過鏈接快速分享給團隊成員，團隊成員獲得鏈接後可自由查看，當產品需求文檔有修改時，團隊成員仍可通過鏈接查看最新版本。

請點擊輸入圖片描述

使用摹客等高效便捷的產品文檔撰寫工具，可以簡化產品文檔撰寫流程，提升產品經理的文檔撰寫能力，讓產品經理事半功倍。

總結

產品需求文檔作為產品開發團隊的重要溝通文檔，文檔的質量好壞會直接影響到各部門是否能夠明確產品的功能和邏輯。一份簡潔易懂、邏輯清晰的產品需求文檔，可以讓團隊溝通更加高效，從而有效提高產品開發團隊的工作效率。

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 copyArray(packets, offset); }

public int[] getBytes() { return copyArray(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.arraycopy(r1, 0, r3, 0, r1.length);

System.arraycopy(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 (i0) { i ++ }; // 錯誤, { 和 } 在同一行

if (i0) {

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 來代替在字符串中使用\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）使用，用 PrintWrite 來代替它。

如何書寫Java項目的開發文檔

我現在公司是CMMI4認證的，最近我項目組在開始新產品，我負責了大部分文檔編寫。。

人員流動是項目進行中比較讓人頭疼的事情。做好規範文檔，可以讓代碼看起來比較像出自同一人之手。要做java開發文檔得做不少功夫，有需求規格說明書、詳細設計說明書、軟件功能規格說明書、數據庫設計說明書、編碼規範等。比較重要的是 軟件功能描述、數據庫設計、編碼規範，這樣，及時有人員流動的話，新人看了文檔，也能比較快的了解功能需求、數據庫設計、編碼規範，更快的上手項目。先看看你需要什麼文檔，然後去文庫里搜索，就有相應的模板，找個適合自己項目的模板用。

北大青鳥java培訓：Java編程開發規範及其技巧？

在用Java進行開發前，一定要牢牢遵守Java的開發規範，只有這樣你的Java開發之路才能更加順暢。

而掌握相應的Java開發技巧，則可以讓你工作起來事半功倍。

那在編寫代碼時有什麼開發規範和技巧呢？電腦培訓給你詳細介紹一下吧。

1、代碼編寫規範：代碼編寫遵守Java通用開發規範和必聯代碼開發規範；每個類及方法都要有合理的注釋，並且對注釋要持續維護；根據接口需求編寫單元測試用例，再編寫實現類使得單元測試通過，如此循環往複以使得所有的單元測試通過；要求每個Java方法的代碼行數不能超過100行；代碼編寫按照功能劃分，一個接口分為多個方法，每一個方法做什麼事情，做到思路清晰；接口設計盡量做到多兼容性，方便後期開發。

2、數據庫設計及SQL規範不使用MySQL數據庫外鍵約束，通過應用程序邏輯實現關聯約束；適當建立索引，經常作為查詢條件的字段、唯一性程度高、長度不是很長的、數量不宜太多，一般一個表的索引數目在5個以內；表名長度不能超過30個字符，表名最好選擇一個單詞，能夠準確清晰明了地表示實體含義，若必須多個單詞則以下劃線“_”分隔，單詞所有字母均小寫；