6.1 變量使用
1、不允許隨意定義全局變量。
2、一個變量只能有一個用途；變量的用途必須和變量的名稱保持一致。
3、所有變量都必須在類和函數最前面定義，並分類排列。
6.2 數據庫操作
1、查找數據庫表或視圖時，只能取出確實需要的那些字段。
2、使用無關聯子查詢，而不要使用關聯子查詢。
3、清楚明白地使用列名，而不能使用列的序號。
4、ASP操作時只在必要時創建RecordSet對象
6.3 對象使用
儘可能晚地創建對象，並且儘可能早地釋放它。
6.4 模塊設計原則
1、不允許隨意定義公用的函數和類。
2、函數功能單一，不允許一個函數實現兩個及兩個以上的功能。
3、不能在函數內部使用全局變量，如要使用全局變量，應轉化爲局部變量。
4、函數與函數之間只允許存在包含關係，而不允許存在交叉關係。即兩者之間只存在單方向的調用與被調用，不存在雙向的調用與被調用。
結構化要求
1、用 IF 語句來強調只執行兩組語句中的一組。禁止 ELSE GOTO 和 ELSE RETURN。
2、用 CASE 實現多路分支而不是多個IF
3、避免從循環引出多個出口。
4、函數只有一個出口。
5、不使用條件賦值語句。
6、避免不必要的分支。
7、不要輕易用條件分支去替換邏輯表達式
6.6 函數返回值原則
1、避免使用結構體等複雜類型
2、使用邏輯類型：該函數只需要獲得成功或者失敗的返回信息時候
3、使用int 類型：錯誤代碼用負數表示，成功返回0
七、數據庫命名規範:
1、表命名：用一個或三個以下英文單詞組成，單詞首字母大寫，如：DepartmentUsers；
2、表主鍵名稱爲：表名+ID，如Document表的主鍵名爲：DocumentID
3、存儲過程命名：表名+方法,如：p_my_NewsAdd,p_my_NewsUpdate;
4、視圖命名：View_表名，如：ViewNews;
5、Status爲表中狀態的列名，默認值爲0，在表中刪除操作將會改變Status的值而不真實刪除該記錄；
6、Checkintime爲記錄添加時間列，默認值爲系統時間；
7、表、存儲過程、視圖等對象的所有都爲dbo，不要使用數據庫用戶名，這樣會影響數據庫用戶的更改。
八、註釋規範
8.1 概述
1、註釋要求英文及英文的標點符號。
2、註釋中，應標明對象的完整的名稱及其用途，但應避免對代碼過於詳細的描述。
3、每行註釋的最大長度爲100個字符。
4、將註釋與註釋分隔符用一個空格分開。
5、不允許給註釋加外框。
6、編碼的同時書寫註釋。
7、重要變量必須有註釋。
8、變量註釋和變量在同一行，所有註釋必須對齊，與變量分開至少四個“空格”鍵。例：
int m_iLevel,m_iCount; // m_iLevel ....tree level
// m_iCount ....count of tree items
string m_strSql; //SQL
9、典型算法必須有註釋。
10、在循環和邏輯分支地方的上行必須就近書寫註釋。
11、程序段或語句的註釋在程序段或語句的上一行
12、在代碼交付之前，必須刪掉臨時的或無關的註釋。
13、最終發佈時，可以依需要刪除部分註釋。
8.2 自建代碼文件註釋
對於自己創建的代碼文件（如函數、腳本），在文件開頭，一般編寫如下注釋（VBS則第行加')（可採用中文）：
/******************************************************
FileName:文件名
Edits the Tool:編輯工具
Copyright 2006-2007 開發組名稱
Writer:作者名
Create Date:按月日年格式書寫，月份及日不足10前面補0，例:06/01/2006
Rewriter:修改者名
Rewrite Date:修改日期
Main Content（Function Name、parameters、returns）主要內容及作用，只簡單寫，單獨過程及函數前再加相應註釋
******************************************************/
8.3 方法-過程|函數及相關注釋
一般加如下注釋（可採用中文）
/******************************************************
Depiction：本方法-過程|函數說明
Param：參數說明
Returns：返回值說明
Writer：編寫者
Create Date：時間
******************************************************/
附：數據類型縮寫
整數型 int
長整型 lng
字符型 str
布爾型 boo
單精度 sng
雙精度 dub
字節型 bit
日期型 dat
貨幣型 cur
對象型 obj
自定型 udt
數組 arr
錯誤 err
別在程序中使用固定數值，用常量代替。
別用字符串常數。用資源文件。
避免使用很多成員變量。聲明局部變量，並傳遞給方法。不要在方法間共享成員變量。如果在幾個方法間共享一個成員變量，那就很難知道是哪個方法在什麼時候修改了它的值。
必要時使用enum 。別用數字或字符串來指示離散值。
別把成員變量聲明爲 public 或 protected。都聲明爲 private 而使用 public/protected 的Properties.
不在代碼中使用具體的路徑和驅動器名。 使用相對路徑，並使路徑可編程。
永遠別設想你的代碼是在“C:”盤運行。你不會知道，一些用戶在網絡或“Z:”盤運行程序。
應用程序啓動時作些“自檢”並確保所需文件和附件在指定的位置。必要時檢查數據庫連接。出現任何問題給用戶一個友好的提示。
如果需要的配置文件找不到，應用程序需能自己創建使用默認值的一份。
如果在配置文件中發現錯誤值，應用程序要拋出錯誤，給出提示消息告訴用戶正確值。
錯誤消息需能幫助用戶解決問題。永遠別用象"應用程序出錯", "發現一個錯誤" 等錯誤消息。而應給出象 "更新數據庫失敗。請確保登陸id和密碼正確。" 的具體消息。
顯示錯誤消息時，除了說哪裏錯了，還應提示用戶如何解決問題。不要用 象 "更新數據庫失敗。"這樣的，要提示用戶怎麼做："更新數據庫失敗。請確保登陸id和密碼正確。"
顯示給用戶的消息要簡短而友好。但要把所有可能的信息都記錄下來，以助診斷問題。
註釋
別每行代碼，每個聲明的變量都做註釋。
在需要的地方註釋。可讀性強的代碼需要很少的註釋。如果所有的變量和方法的命名都很有意義，會使代碼可讀性很強並無需太多註釋。
行數不多的註釋會使代碼看起來優雅。但如果代碼不清晰，可讀性差，那就糟糕。
如果應爲某種原因使用了複雜艱澀的原理，爲程序配備良好的文檔和重分的註釋。
對一個數值變量採用不是0,-1等的數值初始化，給出選擇該值的理由。
簡言之，要寫清晰，可讀的代碼以致無須什麼註釋就能理解。
對註釋做拼寫檢查，保證語法和標點符號的正確使用。