開發(fā)的技術規(guī)范與實踐

1、ASP.Net平臺開發(fā)的技術規(guī)范與實踐精華總結本言語是以下是本人對.Net平臺開發(fā)實踐的一些點滴總結。這里的技術規(guī)范主要是開發(fā)過程的代碼規(guī)范、數(shù)據(jù)庫設計規(guī)范、Com和.Net互操作規(guī)范；實踐精華是對技術實踐過程中的部分總結。一、代碼規(guī)范良好的代碼風格來自于同一的代碼規(guī)范。風格良好的代碼不僅具備可讀性和可維護性，同時也給人行云流水、賞心悅目之快感。據(jù)Microsoft公司統(tǒng)計，基于微軟平臺的開發(fā)中，有70-80%的印度工程師在完成同類算法或者模塊時，使用的代碼基本一致；而相同的調查中只有20%的中國工程師們是基本一致的。這說明我們的代碼生產(chǎn)過程亟待規(guī)范。實義命名類型、變量、常量、方法等標識符一律

2、采用對應的英文實義；如果涉及到兩個獨立的實義單詞，則中間用下劃線間隔或者單詞首字母大寫（兩種方式都可以）；如果標識符的長度超過了30個字母，則基本上以英文單詞發(fā)音的重讀音節(jié)取選出三個字母，如Repeater用rpt，Management用mgt。大小寫規(guī)則目前一般有兩種大小寫規(guī)則：Pascal大小寫形式，所有單詞第一個字母大寫，其他字母小寫。Camel大小寫形式，除了第一個單詞，所有單詞第一個字母大寫，其他字母小寫。類名使用Pascal大小寫形式 public class HelloWorld（或者Hello_World，以下同，不再贅述） .方法使用Pascal大小寫形式 public cl

3、ass HelloWorld（） void SayHello(string name) . 變量和方法參數(shù)使用Camel 大小寫形式 public class HelloWorld（） int totalCount = 0; void SayHello(string name) string fullMessage = "Hello " + name; . 不要使用匈牙利方法來命名變量以前，多數(shù)程序員喜歡把數(shù)據(jù)類型作為變量名的前綴而m_作為成員變量的前綴。例如： string m_sName；int nAge；然而，這種方式在.NET編碼規(guī)范中是不推薦的。所有變量都用Cam

4、el 大小寫形式，而不是用數(shù)據(jù)類型和m_來作前綴。用name，address，salary等代替nam，addr，sal。別使用單個字母的變量象i，n，x 等。使用 index，temp等。用于循環(huán)迭代的變量例外： 如果變量只用于迭代計數(shù)，沒有在循環(huán)的其他地方出現(xiàn)，允許用單個字母的變量命名，而不是另外取實義名。文件名要和類名匹配例如，對于類HelloWorld，相應的文件名應為helloworld.cs。縮進和間隔n 縮進用TAB，不用 SPACES。n 注釋需和代碼對齊。n 遵循VS2005的自動對齊規(guī)則，不要人為的調整。n 用一個空行來分開代碼的邏輯分組。n 在一個類中，各個方法的實現(xiàn)體必

5、須用空行間隔，大括弧“”需獨立一行。n 在每個運算符和括號的前后都空一格。如： If ( showResult = true ) for ( int i = 0; i < 10; i+ ) / 而不是： if(showResult=true) for(int i= 0;i<10;i+) / 良好的編程習慣n 避免使用大文件。如果一個文件里的代碼超過300400行，必須考慮將代碼分開到不同類中。n 避免寫太長的方法。一個典型的方法代碼在130行之間。如果一個方法發(fā)代碼超過30行，應該考慮將其分解為不同的方法。方法名需能看出它作什么。別使用會引起誤解的名字。如果名字一目了然，就無需用文

6、檔來解釋方法的功能了。n 一個方法只完成一個任務。不要把多個任務組合到一個方法中，即使那些任務非常小。n 使用C# 的特有類型，而不是System命名空間中定義的別名類型。如：int age;string name;object contactInfo; 而不是：Int16 age;String name;Object contactInfo;這么做是基于如下兩點原因：（1）規(guī)范性和一致性；（2）便于跨語言平臺的移植。n 別在程序中使用固定數(shù)值，用常量代替。別用字符串常數(shù)，盡量用資源文件。避免使用很多成員變量，聲明局部變量，并傳遞給方法。不要在方法間共享成員變量，如果在幾個方法間共享一個成員變

7、量，那就很難知道是哪個方法在什么時候修改了它的值。必要時使用enum，別用數(shù)字或字符串來指示離散值。 別把成員變量聲明為 public或 protected。都聲明為private 而使用 public/protected 的Properties。n 不在代碼中使用具體的路徑和驅動器名，使用相對路徑，并使路徑可編程。永遠別設想你的代碼是在"C:"盤運行。你不會知道，一些用戶在網(wǎng)絡或"Z:"盤運行程序。n 應用程序啟動時作些“自檢”并確保所需文件和附件在指定的位置。必要時檢查數(shù)據(jù)庫連接，出現(xiàn)任何問題給用戶一個友好的提示。n 如果需要的配置文件找不到，應用程

8、序需能自己創(chuàng)建使用默認值。如果在配置文件中發(fā)現(xiàn)錯誤值，應用程序要拋出錯誤，給出提示消息告訴用戶正確值。錯誤消息需能幫助用戶解決問題。注釋n 別每行代碼，每個聲明的變量都做注釋。在需要的地方注釋。n 可讀性強的代碼需要很少的注釋，如果所有的變量和方法的命名都很有意義，會使代碼可讀性很強并無需太多注釋。行數(shù)不多的注釋會使代碼看起來優(yōu)雅。如果因為某種原因使用了復雜艱澀的原理，必須為程序配備良好的文檔和詳細的注釋。對注釋做拼寫檢查，保證語法和標點符號的正確使用。 二、數(shù)據(jù)庫設計規(guī)范表格分類與命名n 數(shù)據(jù)表的分類u 系統(tǒng)表支撐業(yè)務模型的數(shù)據(jù)表，如流程模型、系統(tǒng)管理相關表。u 業(yè)務表產(chǎn)品提供的針對業(yè)務的通

9、用功能模塊相關表，如通用業(yè)務查詢等。u 用戶表用戶二次開發(fā)使用的與具體業(yè)務相關的數(shù)據(jù)表。n 數(shù)據(jù)表的命名u 所有表格命名一律以字母“T”開頭（Table），并且用實義單詞以下劃線“_”間隔。u 系統(tǒng)表系統(tǒng)表前綴為：TSYS_u 業(yè)務表前綴為：TBIZ_u 用戶表由用戶自行定義，但是建議不要與系統(tǒng)表和業(yè)務表的命名規(guī)則重復。n 字段的命名字段的命名規(guī)則參照代碼標識符的命名規(guī)則，但是注意避開數(shù)據(jù)庫的保留字。比如不要采用這樣的字段名：index，field，password，id，Oracle，SQL等等。對于涉及到技術核心的系統(tǒng)表，為了防止剖析，建議采用類似“F1，F(xiàn)2，F(xiàn)3Fn”的方式命名。但是不

10、要采用“F0”，因為這個名稱在某些數(shù)據(jù)庫中不被允許，比如Interbase。索引的建立n 索引是一把雙刃劍，索引將提高查詢的效率，但是卻降低了insert/delete/update 的效率。通常情況下，對數(shù)據(jù)的編輯頻度和時限要求遠遠低于對數(shù)據(jù)庫的查詢要求，因此對于記錄很多且頻繁查詢的數(shù)據(jù)表，必須建立索引。n 大多數(shù)數(shù)據(jù)庫為主鍵字段自動創(chuàng)建索引，注意為外鍵創(chuàng)建索引。n 不要索引大字段，這樣作會讓索引占用太多的存儲空間。n 盡量不要索引頻繁編輯的小型表。n identify字段不要作為表的主鍵與其它表關聯(lián)，這將會影響到該表的數(shù)據(jù)遷移。如果考慮支持多數(shù)據(jù)庫，建議主鍵采用程序生成的唯一值。n 如果一

11、個大型表需要頻繁的做insert/delete/update操作，同時也需要做高并發(fā)量的查詢，那么建議根據(jù)數(shù)據(jù)的訪問頻度對表作拆分，而后建立索引。過程與函數(shù)數(shù)據(jù)庫廠商為了凸現(xiàn)自身的優(yōu)勢，都提供了豐富且個性化的過程與函數(shù)。為了提升產(chǎn)品的伸縮性和數(shù)據(jù)無關性，請不要使用與特定數(shù)據(jù)庫相關的過程與函數(shù)，也不推薦采用Store Procedure，建議使用應用服務器的中間層業(yè)務對象。字段/域的定義n 盡量避免使用Blob，如果一定要用，請不要索引blob，并且不要定義多個blob。n 不要使用日期字段，改用字符串char(19)替代，如：2008-12-09 12:22:08。n 對于確定長度的串，請固定

12、字段類型的長度，如char（80），不要采用varchar。n 對于值類型字段，請使用對應的數(shù)據(jù)庫值類型，而不要用字符串。三、Com和.Net互操作規(guī)范.NET 技術已經(jīng)成為微軟平臺的主流，但是在Win32時代開發(fā)了很多COM、DCOM組件，由于在開發(fā)COM組件時投入了大量的人力、財力，如何在.NET環(huán)境下重用這些COM組件就顯得更有意義。.NET支持運行時通過COM、COM、本地WinAPI調用與未托管代碼的雙向互操作性，要實現(xiàn)互操作性，必須首先引入.NET Framework的 System.Runtime.InteropServices命名空間。C#的語法為： using System.

13、Runtime.InteropServices; （1）.NET訪問API .NET允許C訪問未托管的DLL的函數(shù)。如要調用Windows User32.dll的MessageBox函數(shù)：int MessageBox(HWND hwnd,LPCTSTR lpText, LPCTSTR lpCaption,UINT uType) 可以聲明一個具有DLLImport屬性的static extern方法： using System.Runtime.InteropServices； DllImport(“user32.dll”) static ertern int MessageBox(int hwn

14、d,string text,string caption,int type); 然后在代碼里面直接調用就可以了。這里要注意在調用返回字符串的API中使用StringBuilder對象。 （2）.NET訪問COM組件 從.NET調用COM組件比較容易，只要使用tlbimp.exe產(chǎn)生COM的裝配形式的WarpClass，然后在.NET項目中調用即可。注意COM的類型信息通過Type Library文件描述，.NET裝配件是自描述的。Tlbimp的作用是從COM組件及其類型信息中產(chǎn)生自描述的裝配件。1編寫Com組件編譯生成一個ComAccount.dll。2. 產(chǎn)生.NET可訪問的包裝類（asse

15、mbly），使用TlbImp.exe產(chǎn)生.NET裝配件。 TlbImp /out：NetAccount.dll ComAccount.dll ( 3 )在.NET代碼中訪問 .NET代碼只需引用NetAccount.dll,就可以像訪問.NET的裝配件一樣訪問COM組件。四、異常處理異常處理的原則在應用程序級（線程級）錯誤處理器中處理所有的一般異常。遇到“意外的一般性錯誤”時，此刻錯誤處理器應該捕捉異常，給用戶提示消息，在應用程序關閉或用戶選擇“忽略并繼續(xù)”之前記錄錯誤信息。n 不必每個方法都用try-catch，當特定的異?？赡馨l(fā)生時才使用。比如，當寫文件時，處理異常FileIOExcept

16、ion。別寫太大的 try-catch 模塊。如果需要，為每個執(zhí)行的任務編寫單獨的 try-catch 模塊。這將有助于找出哪一段代碼產(chǎn)生異常，并給用戶發(fā)出特定的錯誤消息。如果應用程序需要，可以編寫自己的異常類。自定義異常不應從基類SystemException派生，而要繼承于IApplicationException。n 在開發(fā)階段，不必在所有方法中捕捉一般異常?？桃獾姆趴v異常，將幫助在開發(fā)周期發(fā)現(xiàn)大多數(shù)的錯誤。異常處理的提示n 不要捕捉了異常卻什么也不做，看起來系統(tǒng)似乎在正常運行。如果這樣隱藏了一個異常，將永遠不知道異常到底是否發(fā)生，為什么發(fā)生。發(fā)生異常時，給出友好的消息給用戶。但要精確記

17、錄錯誤的所有可能細節(jié)，包括發(fā)生的時間，和相關方法，類名等。永遠別用像“應用程序出錯”，“發(fā)現(xiàn)一個錯誤”等錯誤提示消息，而應給出類似“更新數(shù)據(jù)庫失敗，請確保登陸id和密碼正確?！敝惖木唧w消息。顯示錯誤消息時，還應提示用戶如何解決問題。如：“更新數(shù)據(jù)庫失敗，請確保登陸id和密碼正確?！?，而不是僅僅說“更新數(shù)據(jù)庫失敗”。n 顯示給用戶的消息要簡短而友好。但要把所有可能的信息都記錄下來，以助診斷問題。異常處理的代碼實例推薦如下異常處理模式：void ReadFromFile ( string fileName ) try / 讀文件. catch (FileIOException ex) / 記載異

18、常日志 / 重拋具有針對性的異常信息 throw; 不推薦如下的異常處理模式：void ReadFromFile ( string fileName ) try / 讀文件 catch (Exception ex) / 捕捉一般異常將讓我們永遠不知道到底是文件錯誤還是其他錯誤 / 隱藏異常將我們永遠不知道有錯誤發(fā)生。 return "" 五、對象實例的申請與釋放.Net平臺的垃圾回收機制，可以自動的dispose不再引用的對象實例，所以很多開發(fā)人員并不主動釋放申請的對象資源。事實上，在對象的生命周期結束之前是不會被釋放的。但是，很多時候當對象處于生命周期之內時，我們不再使用它，以便釋放資源提升系統(tǒng)效率。因此，主動釋放申請的資源顯得很有必要。永遠不要把力所能及的事情交給操作系統(tǒng)，及時釋放不再使用的資源是一個好習慣。六、數(shù)據(jù)庫訪問數(shù)據(jù)庫訪問永遠是系統(tǒng)的瓶頸，選擇高效、穩(wěn)健的數(shù)據(jù)庫訪問模式是產(chǎn)品性能的基礎保證。n 永遠不要假設你的應用系統(tǒng)構建與某個數(shù)據(jù)庫之上，因此必須有統(tǒng)一的、透明的數(shù)據(jù)庫訪問機制。采用ADO.Net訪問數(shù)據(jù)庫基于效率和穩(wěn)定性的考量，采用微軟平臺原生的數(shù)據(jù)庫訪問模式ADO.Net。使用ADO.Net