.Net平台開發的技術規范與實踐

以下是本人對.Net平台開發實踐的一些點滴總結。這裡的技術規范主要是開發過程的代碼規范、數據庫設計規范、Com和.Net互操作規范；實踐精華是對技術實踐過程中的部分總結。

一、代碼規范

良好的代碼風格來自於同一的代碼規范。風格良好的代碼不僅具備可讀性和可維護性，同時也給人行雲流水、賞心悅目之快感。

據Microsoft公司統計，基於微軟平台的開發中，有70-80%的印度工程師在完成同類算法或者模塊時，使用的代碼基本一致；而相同的調查中只有20%的中國工程師們是基本一致的。這說明我們的代碼生產過程亟待規范。

實義命名

類型、變量、常量、方法等標識符一律采用對應的英文實義；如果涉及到兩個獨立的實義單詞，則中間用下劃線間隔或者單詞首字母大寫（兩種方式都可以）；如果標識符的長度超過了30個字母，則基本上以英文單詞發音的重讀音節取選出三個字母，如Repeater用rpt，Management用mgt。

大小寫規則

目前一般有兩種大小寫規則：

Pascal大小寫形式，所有單詞第一個字母大寫，其他字母小寫。

Camel大小寫形式，除了第一個單詞，所有單詞第一個字母大寫，其他字母小寫。

類名使用Pascal大小寫形式

public class HelloWorld(或者Hello_World，以下同，不再贅述)
{
...
}

方法使用Pascal大小寫形式

public class HelloWorld()
{
void SayHello(string name)
{
...
}
}

變量和方法參數使用Camel 大小寫形式

public class HelloWorld()
{
int totalCount = 0;
void SayHello(string name)
{
string fullMessage = "Hello " + name;
...
}
}

不要使用匈牙利方法來命名變量

以前，多數程序員喜歡把數據類型作為變量名的前綴而m_作為成員變量的前綴。例如： string m_sName；int nAge；

然而，這種方式在.NET編碼規范中是不推薦的。所有變量都用Camel 大小寫形式，而不是用數據類型和m_來作前綴。

用name，address，salary等代替nam，addr，sal。

別使用單個字母的變量象i，n，x 等。使用 index，temp等。用於循環迭代的變量例外：

如果變量只用於迭代計數，沒有在循環的其他地方出現，允許用單個字母的變量命名，而不是另外取實義名。

文件名要和類名匹配，例如，對於類HelloWorld，相應的文件名應為helloworld.cs。

縮進和間隔

縮進用TAB，不用 SPACES。

注釋需和代碼對齊。

遵循VS2005的自動對齊規則，不要人為的調整。

用一個空行來分開代碼的邏輯分組。

在一個類中，各個方法的實現體必須用空行間隔，大括弧“{}”需獨立一行。

在每個運算符和括號的前後都空一格。如：

If ( showResult == true )
{
for ( int i = 0; i < 10; i++ )
{
//
}
}

而不是：

if(showResult==true)
{
for(int i= 0;i<10;i++)
{
//
}
}

良好的編程習慣

避免使用大文件。如果一個文件裡的代碼超過300～400行，必須考慮將代碼分開到不同類中。

避免寫太長的方法。一個典型的方法代碼在1～30行之間。如果一個方法發代碼超過30行，應該考慮將其分解為不同的方法。

方法名需能看出它作什麼。別使用會引起誤解的名字。如果名字一目了然，就無需用文檔來解釋方法的功能了。

一個方法只完成一個任務。不要把多個任務組合到一個方法中，即使那些任務非常小。

使用C# 的特有類型，而不是System命名空間中定義的別名類型。如：

int age;

string name;

object contactInfo;

而不是：

Int16 age;

String name;

Object contactInfo;

這麼做是基於如下兩點原因：（1）規范性和一致性；（2）便於跨語言平台的移植。

別在程序中使用固定數值，用常量代替。別用字符串常數，盡量用資源文件。

避免使用很多成員變量，聲明局部變量，並傳遞給方法。

不要在方法間共享成員變量，如果在幾個方法間共享一個成員變量，那就很難知道是哪個方法在什麼時候修改了它的值。必要時使用enum，別用數字或字符串來指示離散值。

別把成員變量聲明為 public或 protected。都聲明為private 而使用 public/protected 的Properties。

不在代碼中使用具體的路徑和驅動器名，使用相對路徑，並使路徑可編程。永遠別設想你的代碼是在"C:"盤運行。你不會知道，一些用戶在網絡或"Z:"盤運行程序。

應用程序啟動時作些“自檢”並確保所需文件和附件在指定的位置。必要時檢查數據庫連接，出現任何問題給用戶一個友好的提示。

如果需要的配置文件找不到，應用程序需能自己創建使用默認值。如果在配置文件中發現錯誤值，應用程序要拋出錯誤，給出提示消息告訴用戶正確值。錯誤消息需能幫助用戶解決問題。

注釋

別每行代碼，每個聲明的變量都做注釋。在需要的地方注釋。

可讀性強的代碼需要很少的注釋，如果所有的變量和方法的命名都很有意義，會使代碼可讀性很強並無需太多注釋。行數不多的注釋會使代碼看起來優雅。

如果因為某種原因使用了復雜艱澀的原理，必須為程序配備良好的文檔和詳細的注釋。

對注釋做拼寫檢查，保證語法和標點符號的正確使用。

二、數據庫設計規范

表格分類與命名

數據表的分類

系統表   支撐業務模型的數據表，如流程模型、系統管理相關表。

業務表   產品提供的針對業務的通用功能模塊相關表，如通用業務查詢等。

用戶表   用戶二次開發使用的與具體業務相關的數據表。

數據表的命名

所有表格命名一律以字母“T”開頭（Table），並且用實義單詞以下劃線“_”間隔。

系統表   系統表前綴為：TSYS_

業務表前綴為：TBIZ_

用戶表由用戶自行定義，但是建議不要與系統表和業務表的命名規則重復。

字段的命名

字段的命名規則參照代碼標識符的命名規則，但是注意避開數據庫的保留字。比如不要采用這樣的字段名：index，field，password，id，Oracle，SQL等等。

對於涉及到技術核心的系統表，為了防止剖析，建議采用類似“F1，F2，F3……Fn”的方式命名。但是不要采用“F0”，因為這個名稱在某些數據庫中不被允許，比如Interbase。

索引的建立

索引是一把雙刃劍，索引將提高查詢的效率，但是卻降低了insert/delete/update 的效率。

通常情況下，對數據的編輯頻度和時限要求遠遠低於對數據庫的查詢要求，因此對於記錄很多且頻繁查詢的數據表，必須建立索引。

大多數數據庫為主鍵字段自動創建索引，注意為外鍵創建索引。

不要索引大字段，這樣作會讓索引占用太多的存儲空間。

盡量不要索引頻繁編輯的小型表。

identify字段不要作為表的主鍵與其它表關聯，這將會影響到該表的數據遷移。如果考慮支持多數據庫，建議主鍵采用程序生成的唯一值。

如果一個大型表需要頻繁的做insert/delete/update操作，同時也需要做高並發量的查詢，那麼建議根據數據的訪問頻度對表作拆分，而後建立索引。

過程與函數

數據庫廠商為了凸現自身的優勢，都提供了豐富且個性化的過程與函數。

為了提升產品的伸縮性和數據無關性，請不要使用與特定數據庫相關的過程與函數，也不推薦采用Store Procedure，建議使用應用服務器的中間層業務對象。

字段/域的定義

盡量避免使用Blob，如果一定要用，請不要索引blob，並且不要定義多個blob。

不要使用日期字段，改用字符串char(19)替代，如：2008-12-09 12:22:08。

對於確定長度的串，請固定字段類型的長度，如char（80），不要采用varchar。

對於值類型字段，請使用對應的數據庫值類型，而不要用字符串。

三、Com和.Net互操作規范