目錄
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 do
begin
…
i:= i + 1; //Add one to i
end;
注釋“//Add one to i”在此是毫無意義的，當然並不是說簡單的語句（類似於：i : = i + 1）就不需要注釋。因為簡單的語句往往會起到十分重要的作用，所以，如果這條語句會使人產生疑問或者讓人難以理解，那麼就要將此語句的作用標記下來。
4． 不要試圖在注釋中創建組合圖案，除非你認為這十分必要。因為在保持圖案完整美觀的情況下修改注釋是非常困難的。。
5． 要區分臨時注釋和永久注釋，你可以用你的方法在注釋中放置特殊符號來區分。這樣的好處是易於查找。
6． 對語句的更改要映射到相應的注釋中。
7． 注釋與代碼間要留有明顯的間隔，要一眼就能夠分清楚哪是語句哪是注釋。可以將注釋放在代碼行的前一行、後一行或留有至少兩個空格緊跟在代碼的後面，但是在代碼與注釋在同一行時不要使代碼跟在注釋的後面，另外，不要將在注釋放在代碼中間。
