《Ioas项目开发规范（JAVA部分）》.docVIP

Ioas開發規範 開發規範 (提交稿) 北京****軟體股份有限公司 2011年7月 文檔說明 本文檔所涉及到的文字、圖表等，僅限於北京****軟體股份有限公司內部使用，未經雙方書面許可，請勿擴散到協力廠商。 文件屬性 屬性 內容 客戶名稱： ****軟體股份有限公司 項目名稱： ****軟體股份有限公司產品 文檔主題： 產品開發規範 文檔編號： 文檔版本： 0.1 版本日期： 2011-7-12 文檔狀態： 提交稿 作者： 范衛營 文檔變更 版本 修訂日期 修訂人 描述 1.0 2011-7-12 范衛營 創建文檔結構 文檔送呈 單位 姓名 目的 **** 審閱 **** 參閱 目 錄 (提交稿) 1 1 概述 5 1.1 最根本原则 5 2 程序设计标准 6 2.1 命名约定 6 2.2 注释约定 7 2.3 快速浏览JavaDoc 8 3 门户系统开发规范 10 3.1 整体包结构说明 10 3.1.1 常用包结构 11 3.1.2 功能包结构 12 3.2 命名规则 13 3.2.1 共用类 13 3.2.2 业务层 13 3.2.3 展现层 13 3.2.4 模型层 14 3.2.5 持久层 14 3.2.6 XML配置 14 3.2.7 资源文件 19 3.2.8 事务命名约束 19 概述 本文提供一整套編寫高效可靠的Java代碼的標準、約定和指南。它們以安全可靠的軟體工程原則為基礎，使代碼易於理解、維護和增強。而且，通過遵循這些程式設計標準，你作為一個Java軟體發展者的生產效率會有顯著提高。經驗證明，若從一開始就花時間編寫高品質的代碼，則在軟體發展階段，對代碼的修改要容易很多。最後，遵循一套通用的程式設計標準將帶來更大的一致性，使軟體發展團隊的效率明顯提高。 最根本原則 運用常識 當找不到任何規則或指導方針，當規則明顯不能適用，當所有的方法都失效的時侯： 運用常識並核實這些基本原則。這條規則比其它所有規則都重要。 常識是必不可少的。 程式設計標準 Java的程式設計標準很重要，原因在於它將提高開發團隊各成員的代碼的一致性。一致性的提高會使代碼更易理解，這意味著它更易開發和維護。從而降低了應用程式的總開發成本。 你必須牢記的是：你的Java代碼在你已離開並開始另一個專案之後，會保留相當長的一段時間。因此開發過程中一個很重要的目標就是要確保在開發成員或開發團隊之間的工作可以順利交接，不必花很大的力氣便能理解已編寫的代碼，以便繼續維護和改進以前的工作。如果代碼難以理解，很有可能被廢棄和重寫。 命名約定 我們將在整個標準中討論命名約定，以下是幾個基本點： 使用可以準確說明變數/欄位/類的完整的英文描述符 例如，採用類似firstName，grandTotal 或 CorporateCustomer這樣的名字。雖然象x1，y1或fn 這樣的名字很簡短，輸入起來容易，但是我們難以知道它們代表什麼、結果是什麼含義，因而使代碼難以理解、維護和改進。 採用該領域的術語 如果使用者稱他們的“客戶” (clients) 為“顧客” (customers)，那麼就採用術語Customer 來命名這個類，而不用 Client。許多程式開發者會犯的一個錯誤是，不去使用工業或領域裡已經存在著很完美的術語時，卻生造出一些普通詞彙。 採用大小寫混合，提高名字的可讀性 一般應該採用小寫字母，但是類和介面的名字的首字母，以及任何中間單詞的首字母應該大寫。（駝峰式命名規則） 儘量少用縮寫，但如果一定要使用，就要謹慎地使用 這意味著應該保留一個標準縮寫的列表，明智地從中選取，並且在使用時保持一致。例如，想對單詞“number”採用縮寫，那麼可從 nbr，no 或者 num 中選取一個，說明一下採用了哪一個（具體是哪個倒無所謂），並且只使用這一種形式。 避免使用長名字（不超過15 個字母） 雖然 PhysicalOrVirtualProductOrService 看起來似乎是個不錯的類名，但是這個名字太長了，應該考慮重新給它起個短一點的名字，比如象 Offering。 避免使用相似或者僅在大小寫上有區別的名字 例如，不應同時使用變數名 persistentObject和persistentObjects及anSqlDatabase和 anSQLDatabase這樣的名稱 避免使用底線作為名字的首末字母 以底線為首末字母的名字通常為系統保留，除預處理定義之外，一般不用作用戶命名。更重要的是，底線經常造成麻煩而且難輸入，所以儘量避免使用。 注釋約定 本文還會對注釋進行約定，以下是幾個基本點： 注釋應該增加代碼的清晰度 代碼注釋的目的是要使代碼更易於被同時參與程式設計的開發人員以及其他