第一篇：資源上傳命名規范
資源上傳命名規范
【導語】
為了提高資源可讀性，讓您更加方便查閱資料，網站制定了《第二教育網資源命名規范》文檔，所有上傳的資料必須符合文檔中要求。具體如下：
【高中上傳資源命名規范】
一．標題命名規則:
1、備課資源命名規則：（教案，學案，課件，單元測試）
年級+科目+空格（半角）+資源標題+類別+空格+版本+必選修
例：
高中語文 第六單元《短歌行》教案 新人教版必修2 高中英語 Unit4 Warming Up and Reading課件 新人教版必修1
2、對于試題命名規則：省份+市+學校+年份+年級+科目+類別+版本
例：
江蘇省淮州中學09-10學年高二地理下學期期末考試新人教版
無答案（缺答案改成無答案），掃描版，PDF版，圖片版 例：
江蘇省淮州中學09-10學年高二地理下學期期末考試（掃描版）新人教版
江蘇省淮州中學09-10學年高二地理下學期期末考試（圖片版）新人教版
江蘇省淮州中學09-10學年高二地理下學期期末考試（PDF版）新人教版
江蘇省淮州中學09-10學年高二地理下學期期末考試（無答案）新人教版
3、對于套題命名規則：必須格式相同（包括符號和空格）
例：
2011年高考語文系統集成一輪復習方案 第一編語言知識及運用 新人教版 2011年高考語文系統集成一輪復習方案 第二編文言文閱讀 新人教版
2011年高考語文系統集成一輪復習方案 第三編文學常識、名著閱讀和名句名篇 新人教版 2011年高考語文系統集成一輪復習方案 第四編古代詩歌鑒賞 新人教版 2011年高考語文系統集成一輪復習方案 第五編現代文閱讀 新人教版
二．特殊命名規則：
注意：標題里除書名號和特別標題符號需要除外，其它符號（如：冒號，中間橫線，間隔號，一律用空格代替。對于特殊格式文件名命名規則：
年級+科目+空格（半角）+資源標題+類別+空格+（特殊文件格式）+空格+版本+必選修
例：
高中英語 unit 4 Listening素材(mp3)新人教版必修4 高中英語 unit 4 Listening視頻課件(avi)新人教版必修4 注：凡是swf 格式的文件，統一用命名：（flash）
對于網站上的視頻素材,統一命名年級+科目+標題+視頻+ 類別+視頻格式+版本+必選修 例：高中政治 經濟全球化視頻素材（avi）新人教版必修1 三．命名專業性
1，高一，高二，高三和必選修，不能并形存在
例：該試題原文件名是：高一語文 第六單元《短歌行》教案 新人教版必修2 則命名規則：高中語文
第六單元《短歌行》教案 新人教版必修2 實現：文件名為高中，上傳后臺傳到相對應所屬的，高一年級里
2，綜合網站各科分類，正確判斷資源版本和必選修的準確性
3，根據資源標題及內容，正確判斷資源所屬科目的準確性 4, 根據原件名稱去修改文件名,不能隨意改動文件名的標題
【初中、小學上傳資源命名規范】
一．標題命名規則:
初中：所有“新版”資源需要再標題上標注為（新版）+版本
小學：所有“新版”資源需要再標題上標注為（新版）+版本
1、備課資源的命名規則如下（注：備課包括課件 教案 學案 素材）
1）年級+科目+上下冊+空格（半角）+資源標題+類別+空格+版本
例：三年級語文上冊 第10課《寫給云》課件 西師大版
二年級數學上冊 課間活動教案 北師大版 七年級數學上冊 1.4絕對值教案 浙教版
七年級語文下冊 第一單元導學案 人教新課標版
八年級物理上冊 4.4 光的折射教學課件（新版）新人教版
2）省份+年份+年級+科目+上下冊+資源標題+類別+版本
例：江蘇省灌南縣2012年秋七年級語文上冊《偉人細胞》教案 蘇教版
3）省份+年份+年級+科目+上下冊+資源標題+主題+類別+版本
例：湖北省鐘祥市石牌鎮七年級數學上冊《整式的加減》復習課件 新人教版
安徽省亳州市風華中學七年級語文上冊《第4課 金色花》課件3（新版）新人教版
2、試題資源的命名規則如下（注：試題包括期中 期末 月考 練習單元測試 復習等）
1）省份+年份+年級+科目+上下學期（第一學期）+類別+版本
例：浙江省湖州市吳興區2013年一年級語文上學期期末考試試卷
江蘇省太倉市2012-2013學年七年級英語第一學期期末考試試題 人教新目標版 吉林省鎮賚縣鎮2013屆九年級語文第四次月考試題（掃描版）新人教版 山東省青州市2013年三年級語文下學期期末質量檢測試題（無答案）
吉林省鎮賚縣鎮2013-2014九年級語文第四次月考試題（新版）新人教版 注：年份之間的橫線一定要是這個狀態的“-”
上學期（下學期）與第一學期（第二學期）不可以并存。
“期中考試試題”不可以并存，應該為“期中試題”
“缺答案”要改為“無答案”
掃描版的試題標題要為“掃描版，無答案” 而不應該是“無答案，掃描版”。
2）初中例如有單元、章節、知識點的要改為上冊而不是上學期。下冊與下學期同理。
例：廣東省江門市七年級生物上學期第三單元綜合檢測題（無答案）正確應為：廣東省江門市七年級生物上冊 第三單元綜合檢測題（無答案）
3、中考套題的命名規則如下（注：必須格式相同 包括符號和空格 中考與九年級不可以并存）
1）年份+年級+科目（+復習或總復習）+資源標題+類別+版本
例：
【南方新中考】2013年中考生物復習人的生活需要空氣課件 新人教版
【南方新中考】2013年中考生物復習生物的生殖和發育課件 新人教版
【南方新中考】2013年中考生物復習被子植物的一生課件 新人教版
【南方新中考】2013年中考生物復習專題四 突破中考社會熱點題型課件 新人教版
【備考2014 志鴻優化設計】2013版中考化學總復習基礎講練 第五單元 化學方程式 新人教版（中學教材全解）2013-2014學年九年級化學全冊 第8章 食品中的有機化合物綜合檢測題 滬教版
注：“【】”此符號的使用規則為，必須是參考用書或者是教材類的資源，其余的比較突出的重點需使用“（）”
來顯示。
2）省份+年份+年級+科目（+復習或總復習）+主題+資源標題+版本
例：
廣東省2013年中考政治復習專題檢測試題 過富有情趣的生活
廣東省2013年中考政治復習專題檢測試題 交往藝術新思維
廣東省2013年中考政治復習專題檢測試題 滿懷希望迎接明天
廣東省2013年中考政治復習專題檢測試題 我們的文化
特例：
2012年中考政治一輪復習八上 7.1禮貌待人精品課件 新人教版
2012年中考政治一輪復習七上 1笑迎生活認識自我精品課件 新人教版
2012年中考政治一輪復習九年級 16關注經濟發展精品課件 新人教版 3）小升初的命名規則
例：2014小升初語文知識點專項復習專題一 基礎知識 a o e 教案
湖北省小升初英語 閱讀理解基礎訓練10 北京市小升初語文模擬測試題
（四）4、特殊格式文件名命名規則如下
1）年級+科目+上下冊+空格（半角）+資源標題+類別+（特殊文件格式）+空格+版本
例：五年級英語上冊 lesson1課文朗讀素材（MP3）新路徑（一起）
九年級化學上冊 co2制作及性質素材（flash）新人教版
七年級語文上冊《15 錢塘湖春行》視頻素材（f4v）（新版）新人教版
2）省份+年級+科目+上下冊+空格（半角）+資源標題+類別+（特殊文件格式）+空格+版本
例：重慶市綦江區三江中學八年級語文上冊 了解蓮視頻素材（mpg）
注：
1、凡是swf 格式的文件，統一用命名（flash）其它類型可以根據其文件的屬性來定。
2、標題里除書名號和特別標題符號需要除外，其它符號（如：冒號，中間橫線，間隔號，用空格代替，也有特例，需要自己判斷，下面是例子。
特例：
3、標題里外不符，要以里面的為準進行命題，同時如果標題上沒有知識點而里面有知識點的，要將其復制到標題上。
5、打包文件名命名規則如下
1）省份+年份+年級+科目+上下冊+資源標題+類別+（打包套）+版本
例：湖南省岳陽市七年級英語上冊 Unit 6 Do you like bananas教案（打包5套）人教新目標版
寧夏外國語學校小升初英語專項訓練 完形填空（打包50套）
2）省份+年份+年級+科目+上下冊+資源標題+類別（注：多種）+（打包套）+版本
例：八年級地理上冊 《第一章 第四節 中國的民族》課件+學案+同步練習（打包3套）湘教版
注：多種類別的打包要將知識點加上書名號
二．命名專業性
1、綜合網站各科分類，正確判斷資源版本和上下冊的準確性
2、根據資源標題及內容，正確判斷資源所屬科目的準確性
3、根據原件名稱去修改文件名,不能隨意改動文件名的標題
4、以上文件根據實際情況進行隨時添加修改。
第二篇：Java命名規范
Java包的名字都是由小寫單詞組成。但是由于Java面向對象編程的特性，每一名Java程序員都可以編寫屬于自己的Java包，為了保障每個Java包命名的唯一性，在最新的Java編程規范中，要求程序員在自己定義的包的名稱之前加上唯一的前綴。由于互聯網上的域名稱是不會重復的，所以程序員一般采用自己在互聯網上的域名稱作為自己程序包的唯一前綴。例如： net.frontfree.javagroup
類的名字必須由大寫字母開頭而單詞中的其他字母均為小寫；如果類名稱由多個單詞組成，則每個單詞的首字母均應為大寫例如TestPage；如果類名稱中包含單詞縮寫，則這個所寫詞的每個字母均應大寫，如：XMLExample,還有一點命名技巧就是由于類是設計用來代表對象的，所以在命名類時應盡量選擇名詞。
例如： Circle
interface RasterDelegate;
interface Storing;
方法的名字的第一個單詞應以小寫字母作為開頭，后面的單詞則用大寫字母開頭。例如： sendMessge
變量(Variables)除了變量名外，所有實例，包括類，類常量，均采用大小寫混合的方式，第一個單詞的首字母小寫，其后單詞的首字母大寫。變量名不應以下劃線或美元符號開頭，盡管這在語法上是允許的。
變量名應簡短且富于描述。變量名的選用應該易于記憶，即，能夠指出其用途。盡量避免單個字符的變量名，除非是一次性的臨時變量。臨時變量通常被取名為i，j，k，m和n，它們一般用于整型；c，d，e，它們一般用于字符型。char c;
int i;
float myWidth;
實例變量(Instance Variables)大小寫規則和變量名相似，除了前面需要一個下劃線 int _employeeId;
String _name;
Customer _customer;
常量的名字應該都使用大寫字母，并且指出該常量完整含義。如果一個常量名稱由多個單詞組成，則應該用下劃線來分割這些單詞。
例如： MAX_VALUE
第三篇：oracle命名規范
1、編寫目的
使用統一的命名和編碼規范，使數據庫命名及編碼風格標準化，以便于閱讀、理解和繼承。
2、適用范圍
本規范適用于公司范圍內所有以ORACLE作為后臺數據庫的應用系統和項目開發工作。
3、對象命名規范 3.1 數據庫和SID 數據庫名定義為系統名+模塊名
?
全局數據庫名和例程SID名要求一致
?
因SID名只能包含字符和數字，所以全局數據庫名和SID名中不能含有“_”等字符
3.2 表相關 3.2.1 表空間
?
面向用戶的專用數據表空間以用戶名+_+data命名，如Aud用戶專用數據表空間可命名為Aud_data ?
面向用戶的專用索引表空間以用戶名+_+idx命名 ?
面向用戶的專用臨時表空間以用戶名+_+tmp命名 ?
面向用戶的專用回滾段表空間以用戶名+_+rbs命名
?
面向應用的表空間以應用名+_data/應用名+_idx/應用名+_tmp/應用名+_rbs命名 ?
LOB段數據專用表空間以其數據表空間+_+lobs命名，如上例中數據表空間為Aud_data，則LOB段表空間可命名為Aud_data_lobs 3.2.2 表空間文件
表空間文件命名以表空間名+兩位數序號(序號從01開始)組成，如Aud_data01等 3.2.3 表
表命名要遵循以下原則：
?
一般表采用“系統名+t_+模塊名+_+表義名” 格式構成
?
若數據庫中只含有單個模塊，命名可采用“系統名+t_+表義名”格式構成
?
模塊名或表義名均以其漢語拼音的首字符命名，表義名中漢語拼音均采用小寫，且字符間不加分割符；
?
表別名命名規則：取表義名的前3個字符加最后一個字符。如果存在沖突，適當增加字符（如取表義名的前4個字符加最后一個字符等）?
臨時表采用“系統名+t_tmp_+表義名” 格式構成 ?
表的命名如
dft_gy_cbap：系統名（電費 df）+t_+模塊名（高壓 gy）+_+表義名（抄表安排 cbap）dft_cbbj: 系統名（電費 df）+t_+表義名（抄表標記 cbbj）
dft_tmp_hj: 系統名（電費 df）+tmp+表義名（合計hj）(此處為臨時表)?
關聯表命名為Re_表A_表B,Re是Relative的縮寫，表A和表B均采用其表義名或縮寫形式。
3.2.4 屬性（列或字段）屬性命名遵循以下原則：
?
采用有意義的列名，為實際含義的漢語拼音的首字符，且字符間不加任何分割符
?
屬性名前不要加表名等作為前綴 ?
屬性后不加任何類型標識作為后綴 ?
不要使用“ID”作為列名 ?
關聯字段命名以 “cd+_+關聯表的表義名（或縮寫）+_+字段名”進行 3.2.5 主鍵
?
任何表都必須定義主鍵 ?
表主鍵命名為：“pk+_+表名(或縮寫)+_+主鍵標識” 如“pk_YHXX_IDKH”等 3.2.6 外鍵
表外鍵命名為： “fk+_+表名(或縮寫)+_主表名(或縮寫)+_+主鍵標識” 如“fk_YHLX_YHXX_SFZH”等 3.2.7 CHECK約束
CHECK約束命名為： “chk+_+CHECK約束的列名（或縮寫）” 3.2.8 UNIQUE約束
UNIQUE約束命名為： “unq+_+UNIQUE約束的列名（或縮寫）” 3.2.9 索引
索引的命名為：“表名（或縮寫）+_+列名+_idx”。
其中多單詞組成的屬性列列名取前幾個單詞首字符再加末單詞首字符組成 如yd_kh表khid上的index: yd_kh_khid_idx 3.2.10 觸發器
?
AFTER型觸發器
系統名+tr_+<表名>_+
BEFORE型觸發器
系統名+tr_+<表名>_+bef_
INSTEAD OF型觸發器
系統名+ti_+<表名>+_+
各種類型的觸發器中 i，u，d分別表示insert、update和delete 行級觸發器，后加_row標識，語句級觸發器不加，如 yddftr_CSH_i_row 3.2.11 簇
簇以簇中要存儲的各個表（或表別名）及表間加and的組成命名，即表“A+And+表B?”,如存儲GR(工人)和GRJN（工人技能）表的簇命名為GRAndGRJN 3.3 視圖
視圖命名以系統名v_+模塊名作為前綴，其他命名規則和表的命名類似 3.4 序列
序列命名以seq_+含義名組成 3.5 同義詞
同義詞命名與其基礎對象的名稱一致，但要去除其用戶前綴或含有遠程數據庫鏈接的后綴 3.6 存儲對象相關 3.6.1 存儲過程
存儲過程命名由“系統名+sp+_+存儲過程標識(縮寫)”組成
存儲過程標識要以實際含義的漢語拼音的首字符構成，并用下劃線分割各個組成部分。如增加代理商的帳戶的存儲過程為“sfsp_ZJDLSZH”。3.6.2 函數
函數命名由“系統名+f+_+函數標識”組成 3.6.3 包
包命名由“系統名+pkg+_+包標識”組成 3.6.4 函數文本中的變量采用下列格式命名：
?
參數變量命名采用“i(o或io)+_+名稱”形式，前綴i或o表輸入還是輸出參數 ?
過程變量命名采用“l+_+名稱”形式 ?
全局包變量命名采用“g+_+名稱”形式 ?
游標變量命名采用“名稱+_+cur”形式 ?
常量型變量命名采用“c+_+名稱”形式
?
變量名采用小寫，若屬于詞組形式，用下劃線分隔每個單詞
?
變量用來存放表中的列或行數據值時，使用%TYPE、%ROWTYPE方式聲明變量，使變量聲明的類型與表中的保持同步，隨表的變化而變化 3.7 用戶及角色
?
用戶命名由“系統名稱+_+user+_+名詞(或縮寫)或名詞短語(或縮寫)”組成 ?
角色命名由“系統名稱+_+role+_+名詞(或縮寫)或名詞短語(或縮寫)”組成 3.8 數據庫鏈接
?
數據庫鏈接命名由“遠程服務器名+_+數據庫名+_+link”組成 ?
若遠程服務器名和數據庫名一致，上式“_+數據庫名”部分省去 3.9 命名中的其它注意事項
?
命名都不得超過30個字符。?
不要在對象名的字符之間留空格
?
小心保留詞，要保證你的命名沒有和保留詞、數據庫系統或者常用訪問方法沖突
4、編碼規范 4.1 一般性注釋
4.1.1 注釋盡可能簡潔、詳細而全面
4.1.2 創建每一數據庫對象時都要加上COMMENT ON注釋，以說明該對象的功能和用途；建表時，對某些數據列也要加上COMMENT ON注釋，以說明該列和/或列取值的含義。如：XX表中有CZZT列屬性為NUMBER(10, 0)可加COMMENT ON注釋如下
COMMENT ON COLUMN XX.CZZT IS '0 = 正常, 1 = 等待, 2 = 超時, 3 = 登出' 4.1.3 注釋語法包含兩種情況：單行注釋、多行注釋 單行注釋：注釋前有兩個連字符（--），一般對變量、條件子句可以采用該類注釋。多行注釋：符號之間的內容為注釋內容。對某項完整的操作建議使用該類注釋。4.2 函數文本注釋
4.2.1 在每一個塊和過程（存儲過程、函數、包、觸發器、視圖等）的開頭放置注釋 CREATE [OR REPLACE] PROCEDURE dfsp_xxx ?
4.2.2 傳入參數的含義應該有所說明。如果取值范圍確定，也應該一并說明。取值有特定含義的變量（如boolean類型變量），應給出每個值的含義。
4.2.3 在每一個變量聲明的旁邊添加注釋。說明該變量要用作什么 通常，簡單使用單行注釋就行了，例如
l_sfzh CHAR(11)
--身份證號碼 4.2.4 在塊的每個主要部分之前添加注釋 在塊的每個主要部分之前增加注釋，解釋下—組語句目的，最好是說明該段語句及算法的目的以及要得到的結果，但不要對其細節進行過多的描述
4.2.5 在塊和過程的開頭注釋中還可以增加要訪問的數據庫等信息 4.3 常用SQL語句的編寫規范 4.3.1 CREATE語句
CREATE TABLE dft_dksz（YHBS
VARCHAR2(20)
NOT NULL，ZHGX
DATE，DKKHD
VARCHAR2(24)，CONSTRAINT pk_dksz_yhbs PRIMARY KEY(YHBS))
4.3.2 SELECT語句
查詢語句采用以下原則編寫（可最大化重用共享池中的SQL語句，提高應用程序性能）： ?
將SELECT語句分為5部分:（1）由SELECT開頭，后跟一個顯示查詢結果的列表；
（2）由FROM開頭，后跟一個或多個獲取數據所涉及的表；（3）由WHERE開頭，后跟一個或多個確定所需值的條件；
（4）由GROUP BY開頭，后跟一個或多個表列名，通過這些列以對查詢結果進行匯總；（5）由ORDER BY開頭，后跟一個或多個表列名，通過這些列以對查詢結果進行排序。?
每個部分分行編寫，將每一行的第一個關鍵字與第一行的SELECT尾部對齊，如 SELECT col1, col2, col3
FROM table1 WHERE col1 > col2 GROUP BY col1, col2 ORDER BY col1;?
關鍵字用大寫，列名和表名采用小寫
?
語句中嵌入逗號時，在逗號后面加一空格，當逗號是最后一個字符時，把它放在本行
?
當語句的同一部分要延續到下一行時，按下列格式排列： SELECT col1, col2, col3, col4, col5, col6, col7, col8, col9, col10 ?
將語句中WHERE和AND部分格式化，書寫布局類似于 WHERE
AND
AND ?
當語句中出現括號時，括號的兩邊不留空格
?
在SQL語句使用運算符時，操作兩邊應各留一個空格，如 WHERE X = Y
AND A = B
AND C = D 4.3.3 INSERT語句
INSERT INTO <要插入的表名>
(<列1>, <列2>,.., <列n-1>, <列n>)
VALUES
(<列1值>, <列2值>,.., <列n-1值>, <列n值>)4.3.4 UPDATE語句
UPDATE <要更新的表名>
SET <要更新的列> = <列值> 4.3.5 DELETE語句 DELETE FROM table1 WHERE col1 = '???' 4.4 條件執行語句(IF)編寫規范
條件執行語句IF?ELSE按以下格式編寫 IF <條件表達式> THEN
<一條或多條語句> [ELSE(或ELSIF<條件表達式>)THEN
<一條或多條語句> END IF;注:（1）
在IF?THEN和ELSE(或ELSIF)及ELSE?THEN和END IF間可包含一條或多條PL/SQL語句，而不需要加BEGIN和END（2）
IF?ELSE?ENDIF語句可以嵌套（3）
注意ELSIF的寫法 4.5 循環語句編寫規范 4.5.1 簡單循環語句 LOOP
<零條或多條語句> EXIT WHEN <條件表達式>
<零條或多條語句> END LOOP;4.5.2 FOR循環語句
FOR 變量 IN [變量取值范圍] LOOP
<一條或多條語句> END LOOP;4.5.3 WHILE循環語句 WHILE <條件表達式> LOOP
<一條或多條語句> END LOOP;4.6 函數文本（存儲過程、函數和包等）
?
對于存儲過程、函數等程序塊都要有異常處理部分，在異常部分的最后都要設置OTHERS異常情態處理器，以提高程序的自檢能力，格式如下： BEGIN
? EXCEPTION WHEN excep—name1 THEN
?
WHEN excep—name2 THEN
? WHEN OTHERS THEN
?
END;?
對于子程序、觸發器、包等帶名的程序塊，要使用結束標識，如 CREATE OR REPLACE PROCEDURE XXXsp_XXX IS
? BEGIN
?
END XXXsp_XXX;
第四篇：C#編碼規范及命名規范
山東鋒士自動化系統有限公司
C# 編碼規范
指導規則和最佳實踐 Version 1.0
董毅 2010/4/26
第一條 編碼的風格和細節要求
編碼風格
至少在單一文件中縮進和風格要保持一致，同一行中內容不要太長，最好不要大于10個單詞。不要隨意地或者以容易混淆作用域嵌套關系的方式放置括號，要盡量遵循每個文件中已經使用的體例。
命名約定和規范
1.不要使用晦澀的名稱，起名要簡單易懂
a.避免使用單字母做變量名，比如：i 或者 t。應使用index或者temp進行替代 b.不要縮寫單詞，比如用num代替number 2.使用全大寫字母表示宏，常量，如：LIKE_THIS 3.類，函數和枚舉的名稱的單詞首字母大寫，如：LikeThis public class SomeClass {
const int DefaultSize = 100;public void SomeMethod(){ } } 4.變量的首字母小寫，其他單詞首字母大寫，如：likeThis void MyMethod(int someNumber){ int number;} 5.接口的第一個字母用I開頭
interface IMyInterface {...} 6.私有成員變量以m_開頭，剩余內容遵從首字母大寫的規范
public class SomeClass { private int m_Number;} 7.屬性類以Attribute做后綴，異常類以Exception做后綴
8.命名方法以【動詞】-【目標】組成，比如：ShowDialog（）
9.擁有返回值的方法應該以返回值描述其方法名，比如：GetObjectState（）10.總是使用C#的預定義類型，而不是System命名空間中的別名，比如：
object 而不是
Object string 而不是
String int
而不是
Int32 11.對于基類，類型描述采用大寫字母。當處理.NET中的類型時才保留后綴Type //正確
public class LinkedList
public class LikedList
12.使用有意義的名字空間，比如項目名稱或者公司名稱 13.避免使用類的全稱，而是使用using語句進行引用 14.避免在命名空間內使用using語句
15.將所有framework命名空間嗎放在一起，后面放自定義或第三方的命名空間名
using System;using System.Collections;using System.ComponentModel;using System.Data;using MyCompany;using MyControls;
16.采用委托推斷，不要顯式實例化委托
delegate void SomeDelegate();public void SomeMethod(){ } SomeDelegate someDelegate = SomeMethod;
17.縮進至少在同一文件中要保持統一風格，注釋縮進和其注釋的代碼在同一層次 18.所有注釋要經過認真檢查，不要有不明語義或者錯別字 19.所有成員變量應該定義在前面，和屬性或方法間空開一行
public class MyClass { int m_Number;string m_Name;
public void SomeMethod1(){ } public void SomeMethod2(){ } }
20.局部變量的定義盡可能靠近它的初次使用 21.文件名應該體現其包含的類
22.當使用partial類型且每部分分配一個文件時，以類名+邏輯部分的方式來命名文件
//MyClass.cs public partial class MyClass { } //MyClass.Designer.cs public partial class MyClass { } 23.做大括號總是放在新行中
24.匿名方法模仿普通方法布局，但是大括號要和委托聲明對其
delegate void SomeDelegate(string someString);//正確
void InvokeMethod(){ SomeDelegate someDelegate = delegate(string name){ MessageBox.Show(name);};someDelegate(“Juval”);} //錯誤
void InvokeMethod(){ SomeDelegate someDelegate = delegate(string name){ MessageBox.Show(name);};someDelegate(“Juval”);}
25.沒有參數的匿名方法使用空括號，僅當匿名方法被用于任何委托時才可以省略括號
delegate void SomeDelegate();//正確
SomeDelegate someDelegate1 = delegate(){ MessageBox.Show(“Hello”);};//錯誤
SomeDelegate someDelegate1 = delegate { MessageBox.Show(“Hello”);};
26.在使用Lambda表達式時，模仿一般的方法規范。
delegate void SomeDelegate(string someString);
SomeDelegate someDelegate =(name)=> { Trace.WriteLine(name);MessageBox.Show(name);};
27.當內聯Lambda表達式僅包含一個簡單的語句時，應避免多語句或者返回語句出現在大括號中。可以簡單使用小括號表達：
delegate void SomeDelegate(string someString);
void MyMethod(SomeDelegate someDelegate){ }
//正確
MyMethod(name=>MessageBox.Show(name));
//錯誤
MyMethod((name)=>{Trace.WriteLine(name);MessageBox.Show(name);});注釋
編寫有用的注釋，不要在注釋中重復寫代碼語義。應該編寫的是解釋方法和原理的說明性注釋。
函數
不要在一個函數中包含太多內容，函數的功能要簡單，短小，使人更容易理解，也有利于防錯。
第二條 盡量在代碼中不包含被警告的內容
高度重視警告：使用編譯器的最高警告級別。構建盡量做到干凈利落（沒有警告）。理解所有的警告。通過修改代碼而不是降低警告級別來排除警告。
即使程序一開始似乎能夠正確運行，也還是要這樣做。即使你能夠肯定警告是良心的，仍然要這樣做。因為良性警告的背后可能隱藏著未來指向真正危險的警告。
項目設置和項目結構
1． 總是以4級警告建立項目
2． 在發布版中將警告當作錯誤（注意這不是VS.NET的缺省設置）
3． 永遠不要抑制特定的編譯警告
4． 總是在應用程序的配置文件中顯式地說明支持的運行時版本
5． 避免顯式的自定義版本改向和綁定到CLR程序集
6． 不要在AssemblyInfo.cs中放任何邏輯。除了在AssemblyInfo.cs中，不要在任何文件中放程序集屬性（應包括公司名稱、描述、版權等）7． 所有程序集應該使用相對路徑引用 8． 不允許在程序集中循環引用
9． 努力對同一邏輯應用程序中（通常是一個解決方案）的所有程序集和客戶端使用統一的版本號
10．將Visual Studio.NET應用配置文件命名為App.config，并將其包括在項目中 11． 將Visual Studio.NET缺省的項目結構改為標準的布局，對項目文件夾和文件應用統一的結構 12． 一個發布版本應該包含Debug標記
第三方頭文件
無法修改的庫頭文件可能包含引起警告的構造。如果這樣，可以用自己的包含原頭文件的版本將此文件包裝起來，并有選擇的為該作用域關閉警告，然后在整個項目的其他地方包含此包裝文件。
代碼中盡量不包含未使用的函數，變量
經確認確實不需要使用的函數，變量（不包括為未來使用而設的占位符），可以進行刪除處理。
不要遺漏return語句
PS:例外情況
有時候編譯器可能會發出一些確實無意義的警告。這些警告要經過團隊確認后盡量在局部進行屏蔽，但要做出明確的注釋，說明為什么必須禁用。
第三條 使用自動構建系統 第四條 使用版本控制系統
應確保每次提交的代碼都可以構建成功。
第五條 定期進行代碼審查
互相閱讀彼此的代碼不但可以盡快提高自己的編碼水平，也可以相互借鑒更好的方法。
第六條 一個實體應該只有一個緊湊的職責
一次只解決一個問題：只給一個實體（變量、類、函數、名稱空間、模塊和庫）賦予一個定義良好的職責。應該只選擇目的單一的函數，小而且目的單一的類，和邊界清晰的緊湊模塊。
應該用較小的低層抽象構建更高層次的抽象，要避免將幾個低層抽象集合成一個較大的低層次抽象聚合體。用幾個簡單的行為來實現一個復雜的行為，比反其道而行之更加容易。
第七條 正確，簡單和清晰第一
軟件簡單為美：正確優于速度，簡單優于復雜，清晰優于機巧，安全優于不安全。
要避免使用程序設計語言中的冷僻特性。應該使用最簡單的有效技術。不要使用不必要的操作符重載
構造函數的參數，應該使用命名變量，而不要使用臨時變量
這能夠避免可能的聲明二義性，還經常能使代碼的意圖更加清晰，從而更容易維護，而且也更安全。
第八條 編程中應該知道何時和如何考慮可伸縮性
當數據爆炸性增長時：不要進行不成熟的優化，如果能夠證明優化必要而且非常重要，則應該集中精力改善算法的復雜性，而不是進行小型的優化，比如節省一個多余的加法運算。
為了避免未來可能遭遇到的數據處理容量上的瓶頸問題，應該預先做這些事情：
使用靈活的、動態分配的數據，不要使用固定大小的數組
那種“比現在所需要的最大數組還要大”的數組，在正確性和安全性方面都存在嚴重問題。只有在編譯時大小固定不變的數組才是可接受的。
了解算法的實際復雜性
要留心那些不易發覺的陷阱，比如看似線性的算法實際上要調用其他線性操作，結果算法實際上是二次的。
優先使用線性算法或者盡可能快的算法 盡可能避免劣于線性復雜性的算法
如果面對的是一個O（NlogN）或者O（N2）算法，就必須花費精力尋找替代方案，只有代碼才不至于在數據量顯著增長的情況下陷入深度激增的性能深潭。例如：建議使用范圍成員函數（通常是線性的）而不是反復調用單元素替代函數，后者會很容易在一個線性的操作要調用另一個線性操作時變成二次復雜性。永遠不要使用指數復雜性的算法，除非真的別無選擇
在決定接受指數算法之前，必須盡力尋找替代方案，因為對于指數算法來說，即使是數據量的有限增加，也會使算法的性能急劇下降。
總而言之，要盡可能優先使用線性（或者更好的）算法，盡可能合理的避免使用比線性算法差的多項式算法。竭盡全力避免使用指數算法。
第九條 不要進行不成熟的優化
我們將不成熟的優化定義為這樣的行為：以性能為名，使設計或代碼更加復雜，從而導致可讀性更差，卻沒有經過驗證的性能需求（比如實際的度量數據與目標的比較結果）作為正當理由，因此本質上對程序沒有真正的好處。
因此，默認時，不要把注意力集中在如何使代碼更快上；首先關注的應該是使代碼盡可能的清晰和易讀。
第十條 不要進行不必要的劣化
所謂不成熟的劣化一詞，指的就是編寫如下這些沒有必要的、可能比較低效的程序：
在可以用通過引用傳遞的時候，卻定義了通過值傳遞的參數 在使用前綴++操作符很合適的場合，卻使用后綴版本 在構造函數中使用賦值操作而不是初始化列表
第十一條 盡量減少全局和共享數據
共享會導致沖突：避免共享數據，尤其是全局數據。共享數據會增加耦合度，從而降低可維護性，通常還會降低性能。
名字空間作用域中的對象、靜態成員對象或者跨線程或跨進程共享的對象會減少多線程和多處理器環境中的并行性，往往是產生性能和可伸縮性瓶頸的源頭。建議用通信方式（比如消息隊列）代替數據共享。盡量降低類之間的耦合，盡量減少交互
第十二條 隱藏信息
不要泄密：不要公開提供抽象的實體的內部信息。而應該公開抽象（至少是get/set抽象），而不是數據。
數據只是抽象、概念性狀態的一種可能的具體化而已。如果將注意力集中在概念而不是其表示形式上，就能夠提供富于提示性的接口，并按需要對實現進行調整。比如緩存還是實時地計算，又比如使用不同的表示方式，針對某種使用模式進行優化。
絕對不要將類的數據成員設為public，僅對最需要的類型標記為public，其他的標記為internal。它同樣適用于更大的實體比如程序庫。模塊和程序庫同樣應該提供定義抽象和其中信息流的接口，從而使與調用代碼的通信比采用數據共享方式更安全，耦合度更低。
第十三條 盡量在編譯和連接時檢查錯誤，而不要等到運行時
運行時檢查取決于控制流和數據的具體情況，這意味著很難知道檢查是否徹底。相比而言，編譯時檢查與控制流和數據無關，一般情況下能夠獲得更高的可信度。
第十四條 盡量合理的使用const常量
不變的值更易于理解、跟蹤和分析，所以應該盡可能地使用常量代替變量，定義值的時候，應該把常量作為默認的選項：常量很安全，在編譯時會對其進行檢查。盡量不要強制轉換常量的類型。
例如：
const int x = 0;public const double productWeight = 11.7;private const string productName = “Visual C#”;
第十五條 避免使用語義不清的參數
要避免在代碼中使用諸如42和3.14159這樣的文字常量。它們本身沒有提供任何說明，并且因為增加了檢測的重復而使維護更加復雜。可以用符號名稱和表達式替換它們，比如width*aspectRatio
名稱能夠增加信息，并提供單一的維護點，而程序中到處重復的原始數據是無名的，維護起來很麻煩。常量應該是枚舉或者const值，有合適的作用域和名稱。
重要的特定于領域的常量應該放在名字空間一級
第十六條 盡可能局部的使用變量 第十七條 避免函數過長，避免嵌套過深
過長的函數和嵌套過深的代碼塊的出現，經常是因為沒能賦予一個函數以一個緊湊的職責所致，這兩種情況通常都能夠通過更好的重構予以解決。每個函數都應該是顧其名而能思其義，易于理解的工作單元，要避免將多個小概念單元合并到一個長的函數體中的做法。
一些建議：
盡量緊湊：對一個函數只賦予一種職責
不要自我重復：優先使用命名函數，而不要讓相似的代碼片斷反復出現 優先使用&&：在可以使用&&條件判斷的地方要避免使用連續嵌套的if 不要過分使用try 優先使用標準算法
不要根據類型標簽（type tag）進行分支（switch）第十八條 盡量減少定義性依賴，避免循環依賴
循環依賴是指兩個模塊直接或者間接地相互依賴。所謂模塊就是一個緊湊的發布單元，而互相依賴的多個模塊并不是真正的獨立模塊，而是緊緊膠著在一起的一個更大的模塊，因此，循環依賴有礙于模塊性，是大型項目的禍根。請避免循環依賴。
第十九條 不要引用多余的資源文件 第二十條 盡量不要重載默認的操作符，至少應保證操作符的自然語義不被破壞 第二十一條 優先使用++和—的標準形式。優先調用前綴形式。第二十二條 用小類代替巨類
小類更易于編寫，更易于保證正確、測試和使用。小類更有可能適用于各種不同情況。應該用這種小類體現簡單概念，不要用大雜燴式的類。
第二十三條 要避免使用隱式轉換
在做類型提供隱式轉換之前，請三思而行，應該依賴的是顯式轉換。
隱式轉換有兩個主要的問題：
1.它們會在最意料不到的地方拋出異常
2.它們并不總是能與語言的其他元素有效地配合 第二十四條 將數據成員設為私有的，無行為的聚集
要避免將公用數據和非公用數據混合在一起，因為這幾乎總是設計混亂的標志。信息隱藏是優秀軟件工程的關鍵，應該將所有數據成員都設為私有的，這是類用來保持其不變式的最佳方式。
第二十五條 不要允許異常跨越模塊邊界傳播
最低限度，應用程序必須在以下位置有捕獲所有異常的catch（…）兜底語句，其中大多數都直接適用于模塊：
1.在main函數的附近：捕獲并用日志記錄任何將使程序不正常終止而其他地方又沒有捕獲的異常。
2.在從無法控制的代碼中執行回調附近3.在現場邊界的附近4.在模塊接口邊界的附近
5.在IO，數據庫連接等高危操作附近
第二十六條 如有可能，盡量用算法調用代替手工編寫的循環
對非常簡單的循環而言，手工編寫的循環有可能是最簡單也是最有效的解決方案。但是編寫算法調用代替手工編寫的循環，可以使表達力更強、維護性更好、更不易出錯，而且同樣高效。
第二十七條 編碼慣例
1． 避免在一個文件中放多個類
2． 一個文件應該只對一個命名空間提供類型，避免在同一文件中有多個命名空間 3． 避免一個文件的長度超過500行（除了機器生成的代碼）4． 避免方法定義超過25行
5． 避免超過5個參數的方法，使用結構傳遞多個參數 6． 每行應該不超過80個字符，或者10個單詞 7． 不要手工編輯任何機器生成的代碼
A.如果修改機器生成的代碼，修改代碼格式和風格以符合本編碼標準 B.盡可能使用partial類以分解出需要維護的部分 8． 避免對顯而易見的內容作注釋
A.代碼應該是自解釋的，由可讀性強的變量和方法組成的好的代碼應該不需要注釋 B.參加第一條中的注釋部分
9． 僅對操作的前提、內在的算法等寫文檔 10． 避免方法級的文檔
A.對API文檔采用大量的外部文檔
B.方法級注釋僅作為對其他開發人員的提示 11． 決不要硬編碼數值，聲明一個常量是最好的選擇 12． 僅對本輪就是常量的值使用const修飾符，例如一周的天數 13． 避免對只讀變量使用const修飾符。在此情況下，采用readonly修飾符
public class MyClass { public const int DaysInWeek = 7;public readonly int Number;public MyClass(int someValue){ Number = someValue;} }
14．對任何假設采用assert。平均來講，每五行代碼中就有一行是斷言
using System.Diagnostics;object GetObject(){} object someObject = GetObject();Debug.Assert(someObject!= null);
15． 16． 17． 每行代碼都應該經過白盒測試 僅捕獲已經顯式處理了的異常
在拋出異常的catch語句中，總是拋出最初異常以保持最初錯誤的堆棧位置
catch(Exception exception){ MessageBox.Show(exception.Message);throw;}
18． 定義自定義的異常時
A.從ApplicationException繼承 B.提供自定義的序列化 19． 避免采用friend程序集，因為這樣增加了程序集間的耦合度 20． 避免使用依賴于從特定位置運行的程序集的代碼。21． 盡量減少應用程序集（客戶端EXE程序集）的代碼，采用類庫而不要包含業務邏輯層代碼。22． 避免對枚舉提供明確的值
//正確
public enum Color { Red,Green,Blue } //錯誤
public enum Color { Red=1,Green=2,Blue=3 }
23． 避免對枚舉指定類型
//錯誤
public enum Color : long { Red, Green, Blue }
24． 25． 26． If語句總是使用括號，即使它只包含一句語句 避免使用?:條件運算符 避免使用（#if…#endif），應使用conditional方法代替
[Conditianal(“MySpecialCondition”] public void MyMethod(){}
27． 避免在布爾條件語句中調用函數，賦值到局部變量并檢查它們的值。
bool IsEverythingOK(){} //錯誤
if(IsEverythingOK()){} //正確
bool ok=IsEverythingOK();if(ok){}
28．29． 總是使用從0開始的數組
總是使用一個for循環顯式地初始化一個引用類型數組
public class MyClass {} const int ArraySize=100;MyClass[] array=new MyClass{ArraySize];for(int index=0;index 30． 31． 不用提供public或protected成員變量，而是使用屬性 應盡量使用get/set的自動返回屬性 //錯誤 class MyClass { int m_Number; public int Number { get { return m_Number;} set { m_Number=value;} } } //正確 class MyClass { public int Number { get;set;} } 32． 33． 34． 35． 避免使用new,應使用override替代 在一個密封的類里總是把public和protected方法標記為virtual 永遠不要使用不安全的代碼 合理使用as操作符進行映射 Dog dog = new GermanShepherd();GermanSheperd shepherd = dog as GermanShepherd;if(shepherd!= null){} 36． 37． { 在使用一個委托前總是要先檢查它是否為空（null） 不要提供公有成員變量，使用存取器（accessors）進行替代 public class MyPublisher MyDelegate m_SomeEvent;public event MyDelegate SomeEvent { add { m_SomeEvent += value;} remove { m_SomeEvent-= value;} } } 38． 避免定義事件處理委托，使用EventHandler SomeType obj1;IMyInterface obj2; obj2=obj1 as IMyInterface;if(obj2!= null){ obj2.Method1();} else { //處理可能出現的錯誤 } 44． 不要將可能改變的，或用于數據庫連接的，或者交付給最終客戶使用的任何字符串進行硬編碼，要使用資源文件定義他們 45． 使用String.Empty代替”” //錯誤 string name = “";//正確 string name = String.Empty; 46． 47． 48． 定義長字符串的時候，應該使用StringBuilder，而不是string 永遠不要使用goto語句，除非迫不得已 在switch代碼塊中總要包含一個default項，并且為其設置斷言 int number = SomeMethod();switch(number){ case 1: Trace.WriteLine(”Case 1:“);break;case 2: Trace.WriteLine(”Case 2:“);break;default: Debug.Assert(false);break;} 49．不要使用this引用，除非某些特殊情況，比如從一個構造器中運行另外一個 //一個正確使用this的例子 public class MyClass { public MyClass(string message){} public MyClass():this(”Hello"){} } 50． 不要使用base關鍵詞。除非你想要解決一個子類成員和基類間的名稱沖突，或者運行一個基類構造器 //一個正確使用base的例子 public class Dog { public Dog(string name){} virtual public void Bark(int howLong){} } public class GermanShepherd:Dog { public GermanShepherd(string name):base(name){} public override void Bark(int howLong){ base.Bark(howLong);} } 51． 不要使用GC.AddMemortyPressure()，不要依賴HandleCollector。合理的使用Dispose()和Finalize()方法 52． 一般情況下不要使用check來檢查代碼（防止性能損失），但是在可能的溢出區則使用check來保持代碼的安全性。安全性的優先級永遠高于性能。 int CalcPower(int number,int power){ int result=1;for(int count=1;count<=power;count++){ checked { result*=number;} } return result;} 53． 在代碼中要避免直接使用object數據類型（System.Object），可以使用約束或者as進行替代。 class SomeClass {} //錯誤 class MyClass class MyClass 54．{} 一般而言，不要在通用接口中定義約束。接口級別的約束經常會被強類型所覆蓋 public class Customer //錯誤 public interface IList public interface ICustomerList:IList 1． 總是對應用程序私有的組件，集合等使用強名，這樣可以保證安全性 2． 在應用程序配置文件中使用加密算法，進行安全保護 3． 對不受控制的引用方法，要做適當的安全處理，如加入斷言控制 4． 不要使用SuppressUnmanagedCodeSecurity屬性 5． 不要使用/unsafe來切換TlbImp.exe的默認行為。 6． 在服務器端要使用自定義的安全規則來擴展Microsoft的默認配置，以保證更高級別的安全性 7． 為防止引誘性攻擊，應修改組件級別的運行權限，限制其可能的不安全行為 8． 在編寫Windows程序時，在每個Main（）中都要使用相應的安全規則 前端開發工作規范 為提高團隊協作效率，便于后臺人員添加功能及前端后期優化維護，輸出高質量的文檔，特制訂此文檔。本規范文檔一經確認，前端開發人員必須按本文檔規范進行前臺頁面開發。 【寫在規則前面的話】 項目的可維護性第一。你不是一個人在做事，項目的維護和二次開發可能是直接的或間接的團隊合作。好的可維護性，從四個方面下手： 1）代碼的松耦合，高度模塊化，將頁面內的元素視為一個個模塊，相互獨立，盡量避免耦合過高的代碼，從html,css,js三個層面都要考慮模塊化。 2）良好的注釋。 3）注意代碼的彈性，在性能和彈性的選擇上，一般情況下以彈性為優先考慮條件，在保證彈性的基礎上，適當優化性能。 4）嚴格按照規范編寫代碼。 【命名規則】 為避免命名沖突，命名規則如下： 1）公共組件因為高度重用，命名從簡，不要加前綴； 2）各欄目的相應代碼，需加前綴，前綴為WD姓名拼音的首字母，例如：杰夫前綴為“jf_”，分隔符為下劃線“_”，例如：“jf_imgList”; 3）模塊組件化，組件中的class或id名采用駱駝命名法和下劃線相結合的方式，單詞之間的分隔靠大寫字母分開，從屬關系靠下劃線分隔。例如： html:第五篇：前端開發命名規范范文
css:
.textList{}.text_list X{}
.textList_firstItem{ }.textListFirstItem X{}
4）命名清晰，不怕命名長，怕命名容易沖突，長命名可以保證不會產生沖突，所以css選擇時可以盡量不使用子選擇符，也能確保css優先級權重足夠低，方便擴展時的覆蓋操作：.textList_firstItem{}.textList.firstItem{}
5)命名要有意義，不要使用沒有意義的命名。用英語命名，不要用拼音。
【分工安排】
1)分工原則為公共組件（包括common.css和public.JS）一人維護，各欄目其他人負責，每個欄目正常情況下一人負責，要詳細寫明注釋，如果多人合作，維護的人員注意添加注釋信息，具體注釋細則，詳見注釋規則；
2)VD設計完設計圖后，先和交互設計師溝通，確定設計可行，然后先將設計圖給公共組件維護者，看設計圖是否需要提取公共組件，然后再提交給相應欄目的WD。如果有公共組件要提取，公共組件維護者需對欄目WD說明。
3)如果確定沒有公共組件需提取，交互設計師直接和各欄目的WD交流，對照著VD的設計
圖進行說明，WD完成需求；
4)WD在制作頁面的時候，需先去common文件中查詢是否已經存在設計圖中的組件，如果有，直接調用；沒有，則在app.css和app.JS中添加相應的代碼。
5)WD在制作過程中，發現有高度重用的模塊，卻未被加入到公共組件中，需向公共組件維護人進行說明，然后工作組件維護人決定是否添加該組件。如果 確定添加，則向WD們說明添加了新組件，讓WD們檢查之前是否添加了類似組件，統一更新成新組件的用法，刪除之前自定義的css和js。雖然麻煩，但始終 把可維護性放在首位。
6)公共組件維護者的公共組件說明文檔，需圖片和說明文字配套，方便閱讀。
【注釋規則】
1.公共組件維護者和各欄目WD都需要在文件頭部加上注釋說明：
/**
*文件用途說明
*作者姓名、聯系方式（旺旺）
*制作日期
**/
2.大的模塊注釋方法：
//================
// 代碼用途
//================
3.小的注釋；
//代碼說明
注釋單獨一行，不要在代碼后的同一行內加注釋。
例如：
//姓名
var name = “abc”;V
var name =”abc”;//姓名 X
4.維護人員的注釋方法：盡量根據注釋說明，找到代碼的原作者，讓原作者進行維護，原作者進行維護可以無需添加額外說明，直接進行修改。如果因為特殊原因，無法讓原作者進行維護，需添加額外說明進行注釋。說明文字為：“/*change by xxx)原代碼如下：
<{源代碼}>.新代碼如下:*/
新代碼：
如：var name = “abc”;這段代碼，要將name由“abc”變成“123”，原作者可直接改var name=”123”;非原作者修改，需改成：
/*(change by 杰夫)原代碼如下：<{
var name = “abc”;
}>新代碼如下：*/
var name =”123”;
修改時添加的注釋，在項目通過測試之后，上線前，可以優化掉。
【js規范】
1)底層JS庫采用YUI 2.6.0；
2)統一頭部中只載入YUI load組件，其他組件都通過loader對象加載；
3)js盡量避免使用全局變量，復雜應用寫成組件，通過構造函數實現多態，寫在公共組件或
外部js中，簡單應用直接寫在init函數中，通過命名空間或匿名函數將變量包進閉包中。
【切圖規范】
1．盡量把頁面的背景圖及小圖標整合到一張圖片，用CSS定位方法。（這樣以減少http請求，從而降底網站的下載速度。）
2．尊從內容與頁面樣式的脫離，如需要，同樣也要做到布局與color的脫離。（什么樣的圖片屬于內容：從數據庫里取出來的圖片。凡是不屬于內容的圖片請都用背景。）
1）頁面代碼，做到精簡，邏輯性清楚；（公用部位可以引入進來，比如頭部，腳部）
2）CSS邏輯清析，精簡。可在不改變功能的前提內，做到能更換頁面布局及換色。
CSS樣式每個頁面引入不超過兩個文件，一個是common：它包含整個站點都需用到的公用部分，如整體布局，頭部，腳部，框，按扭等。另一個是當前頁的CSS。（CSS文件引入在2個之內，減少http請求）避免CSS的表達式。
3．將腳本放在底部。（這樣頁面就可以逐步呈現，而且頁面中的可視組件可以盡早下裁。）配合程序開發人員我們需要注意的（xhtml）：
1．了解用戶可編輯上傳修改的“圖片”，“文字”區域的需求。根據需求來定位控制，以保證頁面的穩定顯示。
如圖片，需了解：
1）寬度是否是固定大小，2）寬度最大限度，3）大小不一樣時的居中顯示
如文字，需了解：
1)文字的最大長度。及加“…”省略號區域,2)在測試中經常也會碰到英文無空格情況，得用overflow: hidden的方法隱藏溢出部分。
2．每個頁面加上正確顯示的TITLE。（這個是我經常容易忽視的）
3．在頁面中盡量完成每步交互效果，包括既時響應的。
4．提交程序員的demo必須是連貫的，交互效里齊全，而且經過自已在IE6.0，IE7.0，IE8.0，FIREFOX等瀏覽器的一次以上的整體測試。
用戶體驗方面需要注意的：
1．每個連接，按鈕要做上鼠標hover時的一個變化效果（如果hover時是換一張背景圖片，請把這兩張圖片整合在一張圖片中，以防止在hover時，頁面還在download變化的那張圖片，這樣會出現那個按鈕無圖的間隔）；
2．Input有個label，可以讓用戶在點擊字時，光標自動跳入相應input中；
3．圖片應該有alt屬性，以備圖片阻止時，文字的替換。
本文由世紀淘商城()整理分享！版權歸原作者所有！
點擊咨詢 