Delphi編碼規格作者：Tulipsys 更新日期：2003年12月16日目錄1． 一般的慣例（命名- 縮排與空格- 邊距- 大小寫- 註）2． 語句（begin…end語句-if語句-case語句-for語句-while語句-repeat語句-with語句-異常處理語句）3． 過程與函數（命名與格式-形參-變數-類型-自訂類型）4． 物件導向相關（類別的命名與格式-字段-方法-屬性-方法的實現）制定編碼規範的目的是為了使一組程式設計師產生相同風格的程式碼，使一個團隊形成並保持一定的風格。如果這個目標能夠實現，那麼整個專案的文件看起來就像是一個程式設計師寫的。好性很好玩，但這樣的好處是每個程式設計師的程式碼都易於為他人所理解，從而會在很大程度上提高程式碼的可維護性，也因此會降低維護費用。對任何團隊來說，這均是十分理想的境界。對於個人，選擇或自我產生一種編碼規範，並堅持這個規範，同樣會產生良好的效果。順便提一下這是一個十分誘人的目標，不過不太難實現。每種程式設計語言都有屬於自己的編碼規範，編碼規範可以說是經驗的總結，當然也要藉鏡其他的程式設計語言的規範。所以，向別人學習是十分重要的。其次，編碼規範的使用是為了簡化程式設計師的工作，「簡化」的意思不是減少程式碼量（相反，很多時候遵從規範會帶來更多的程式碼），而是減少程式設計師在維護程式碼時的勞動量。程式設計是一種非常複雜的工作，處理各種各樣的關係是令人生畏的，而且各種關係之間還有著千絲萬縷的聯繫。程式設計師應將大部分精力用來處理關係，而避免在過於細節的問題上浪費心機。如果他一眼就能夠明白程式的思路和結構，那麼對維護方案就會很快形成。而且，編碼規範應該是一個非常人性化的規範，你可以參考，也可以修改，但要確保易於使用。但是在一個小組中要確保大家使用同樣的規範。程式設計是非常靈活的工作，只有靈活的思考，靈活的應用，才可能得到好的結果。另外，使用規範在很大程度上是為了減少程式設計師的記憶負擔。人的思考能力是極為優秀的，而記憶則十分可憐，我們整天面對電腦，她要幫我們做得很重要的事情應該是記憶。所以盡可能發揮程式設計師的思考優勢是我們的目標之一。最後，程式設計工具對編碼規範有很大的影響，而這個影響來自於開發商的程式設計風格。同樣基於C++，在Microsoft Visual C++和Borland C++ Builder中我們不會使用完全相同的編碼規格。 Microsoft和Borland有著各自不同的而且十分鮮明的風格。作為用戶，我們可以在此基礎上有所改變，但是這是有限制的。其實，在做出對供應商和開發工具的選擇時，我們同時確定了我們未來的風格。 1. 一般的慣例1.1 命名命名的基本原則是名稱要能明確表示資料的功能。 Object Pascal支援長檔名。名稱應該使用動詞、名詞或二者的組合。絕對不可以使用Delphi中定義的保留字和關鍵字，而且盡量不要使用其他語言中定義的保留字和關鍵字。盡量使用完整的字詞而避免使用縮寫、字首和字尾、底線或其它符號，不建議使用匈牙利命名法。命名規格是為了確保名稱的可讀性。以匈牙利命名法為代表的命名規範制定了許多前綴和後綴以表示資料的類型、作用域或其它各種屬性。在Delphi中，你當然可用這種方法，但這不是推薦的方法。有個原因是這類命名規範帶來太多額外的記憶任務，另一個原因是由Delphi本身的特徵決定的。 Delphi的強制類型檢查會自動監測所有的變數使用狀況，所以只需要我們稍加留心（注意單字的大小寫）而不必費力的添加五花八門的前綴。另外，對資料的考慮要基於意義而不是類型或作用域，注意力應該放在程序結構、邏輯關係和設計思路上。所以在Delphi中只需要使用完整的字詞組合來命名，不要考慮其它，當然應該盡可能的保持簡潔。在一些語句（例如for迴圈）中我們要用到若干個整形數作為計數變數。在此可以簡單的使用i、j、k這三個字母作為變數名稱。這是在Fortran語言中形成並被保留下來的習慣，事實證明這非常好用且易於理解。當然，我們使用更有意義的名稱會產生更好的效果，例如：MyCounter。一般來說i、j、k三個字母已完全夠用了，否則應該劃分出更多的過程或函數。以下是幾個例子：1. SongsList //顯示這是一個歌曲的列表，song使用複數表示歌曲不只一首2. SetCarColor //表示這是一個設定汽車顏色的函數，若定義了一個TCar類，那麼在類別中就使用SetColor作為設定汽車顏色的函數成員。另外要注意布林變數的命名。布林變數的名稱要能明確的表示出True和False的意義。比方說記錄某個檔案是否存在的變量，使用IsFileExisted，就比使用FileExisted好。最後，永遠不要將一個全域變數命名為：Temp或Tmp，但是在過程或函數中如此命名還是允許的。其實對於這條規則存在一點爭議，在有的編碼規範中更為嚴格，如此命名是絕對禁止的，即使是在過程或函數中。但是，很多時候這樣命名的確很方便，尤其對於過程或函數。如果作為全域變量，很可能會出現類型不匹配的賦值語句，雖然此時編譯器會給你很大的幫助，但是難以避免細小錯誤的發生。總之，遵守此規則會產生較好的效果，但是在必要的情況下沒有什麼是要嚴格遵守的。 1.2 縮排和空格每級之間要縮排兩個空格，這樣會使程式層次分明，錯落有致。千萬不要使用製表符，因為製表符的寬度隨不同的設定和應用程式的不同而難以保持一致，可不要指望你的程式只在Delphi中察看。另外要注意編輯器的使用，如果你只選擇了Delphi，那麼沒有什麼問題；如果你同時也使用了Word等文字處理器，請注意要使用適當的字體，以確保每個字母、符號的寬度相同。用Word等文字處理器列印時，也要注意字體的選擇。空格的使用同樣是為了保持程式的整潔，是程式設計師能夠快速明白程式結構。以下是一些規範和相應的例子： 1． 每個單字之間要留一個空格。例如：for TMyClass = class(TObject)2． 在「=」、「<>」、「>=」、「<=」左右要留一個空格；在「:=」和「:」右邊要留一個空格，而左邊不留。例如：if a = b then a:= b；a: integer;3． 保留字和關鍵字與左邊的符號間要留有一個空格，與右邊的符號間不留。例如：PRocedure ShowMessage; overload;4． 括號的使用：在過程和函數的定義和呼叫中，括號與外部的單字和符號之間不留空格；與內部的單字之間不留空格。在if語句的條件判斷中，與and、or等保留字之間要使用空格。例如：function Exchange(a: integer; b: integer); if (a = b) and ((a = c) or (a = d)) then … end;1.3 邊距Delphi編輯器在右邊大約第81個字元處留有一條暗線，實際上在Delphi的預設介面下，當解析度在800*600時，最大化視窗將顯示到該暗線左邊4個字母處。因此，不要將原始碼寫到暗線之外，也就是說每行包含前面和中間的空格不要多於80個字元。如果語句過長，那麼換行完成，換行後要縮排兩個字元。這樣也容易列印，在Delphi中超過暗線的部分不會被列印。如果使用Word等文字處理軟體列印Delphi程序，超出的部分會調到下一行的首部，這樣列印出來的程式將難以閱讀。所以，盡量在寫程式碼的時候做好一切調整，不要把這種工作留到列印的時候進行。換行時要注意保持程式的可讀性，盡量保持完整的部分。作為例子，如果函數過長，那麼再換行時要將某個完整的參數說明換行，而不要只將資料類型宣告換行。下面的前兩種寫法是正確的，後面的幾個寫法都是錯的：function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer): integer; //正確function AdditonFiveInputNumber(a: integer;b: integer;c: integer;d: ineger;e: integer): integer; //正確function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger; e: integer): integer; //錯誤function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger ;e: integer): integer; //錯誤function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer): integer; //錯誤1.4 大小寫所有的自訂名稱中的每個單字的首字母要使用大寫，其它字母使用小寫。 Delphi保留字和關鍵字要全部使用小寫。 Delphi預訂函數的寫法與自訂名稱寫法相同。 Delphi中的基本資料類型要使用小寫，擴充的類別類型要的前兩個字母要大寫（類別類型的首字母是“T”）。以下是一些範例：1. 自訂名稱：MyFavouriteSong, CarList;2. 保留字：if (a = b) and ((a = c) or (a = d)) then … end;3. Delphi預定義函數：ShowMessage('Everything all right');4. Delphi擴充類別類型：MyStrings = TStrings.Create;1.5註解Delphi支援兩種註解：區塊註解（{}）和單行註解（//）。註釋的作用是為了解釋程式的設計思路，幫助程式設計師盡快明白兩年前甚至昨天寫的程式的思路。這其實是為了解決記憶問題，大腦不該被過度作為記憶體使用，在程式設計中永遠不要過度依賴大腦，而要盡可能藉助文字。所以說，註釋在程式設計語言中是十分重要的方面，儘管很多人（尤其是初學者，也包括相當數量的程式設計師）對此毫不介意，他們很少寫註釋。註釋的另外一個應用是在程式調試階段，比如說有兩個語句，事先並不知道哪一個更好，於是需要測試：將一條語句前放置"//"（也就是說將這條語句改為註），執行另一個語句，然後再做相反的工作，我們就可以輕鬆做出選擇。如果是一組語句，那就用區塊註釋，但一定注意要將"{"和"}"放在顯眼的位置，比如說放在單獨的上下兩行。以下是一些使用原則：1． 多數情況下，在自訂變數、類型的前面放置註解是有必要的。 2． 多數情況下，在單元文件頂部放置註釋是必要的。在此，註釋中要包含：檔案名稱、建立日期、修改日期、作者、修改作者以及必要的描述。 3． 註解要有意義，不要使用沒用的註解。例如：while i < 8 dobegin … i:= i + 1; //Add one to iend;註解「//Add one to i」在此是毫無意義的，當然並不是說簡單的語句（類似： i : = i + 1）就不需要註解。因為簡單的語句往往會起到十分重要的作用，所以，如果這條語句會使人產生疑問或讓人難以理解，那麼就要將此語句的作用標記下來。 4． 不要試圖在註釋中創建組合圖案，除非你認為這十分必要。因為在保持圖案完整美觀的情況下修改註解是非常困難的。 。 5． 要區分臨時註釋和永久註釋，你可以用你的方法在註釋中放置特殊符號來區分。這樣的好處是易於找到。 6． 語句的變更要對應到對應的註解中。 7． 註解與程式碼間要留有明顯的間隔，要一眼就能夠分辨哪是語句哪是註解。可以將註解放在程式碼行的前一行、後一行或留有至少兩個空格緊跟在程式碼的後面，但是在程式碼與註解在同一行時不要使程式碼跟在註解的後面，另外，不要將在註解放在程式碼中間。