一、老生長談
    Delphi VS VC已經是很古老的話題了，但是我還是想在這里談一下，全是一家之言，如果不同意，請一笑之。
    RAD的好處是很易見的，界面的設計上Delphi實在是高過VC。我要寫一個非常規的透明按鈕，Delphi只要找個控件，點一下鼠標，修改一下Caption就OK了，VC呢？至少要寫上10幾行代碼才能搞定，當然MFC的做法讓人了解windows底層的原理，但是OOP的封裝性沒有很好的體現，開發者要了解所有的底層才能寫代碼，對我對大多數的入門者是個折磨，因為沒必要，現在是開發期限永遠緊張，時間永遠不夠，我們不能指望程序員知道Windows編程的所有的方面，有人對視頻很了解，有人對網絡很在行，但是沒有人是全才，樣樣在行是不現實的，所以封裝是很重要的。如果每次開發新產品我都要在一個透明按鈕或者一個漂亮的界面上花30%甚至更多的時間，那我就去跳河：）Delphi在界面上的確比MFC好！當然不是說MFC就設計不出漂亮的界面，只是花費的時間太長，不值得。
    RAD就真的全是好處？也不是。至少對于初學者不是，因為它讓人誤會編程只是動動鼠標，拉拉框架，最后的結果就是讓人覺得，Delphi就是用來寫界面的，底層什么都不能做。好像MFC程序員都是這么講Delphi程序員的：“你們的程序除了界面漂亮，還能做什么？”錯！其實除了DDK，Delphi什么不能開發？API的頭文件Delphi哪個沒有？Borland沒有轉換的，JEDI都轉換了，即使JEDI沒有轉，自己動手也是一樣的，只要給我C的頭文件，我就可以轉換，JEDI上那篇短短的轉換說明應該是每個Delphi程序員的必備文檔。頭文件轉換了，剩下的就是開寫了，MFC能做的，Delphi也可以！視頻？網絡？directx？Audio？哪個Delphi不能做？

二、子過程
    寫一個事件，很多人就是直接開寫，不管代碼有多長，做的事情有多少，只要是在一個事件里做的，一古腦寫下去，結果是幾個月后重新修改的時候無從下手，因為代碼段實在太長了。那么為什么不把代碼段拆開呢？人的注意力有有限的，超過100行的代碼一口氣看下來會暈的，Delphi的前輩告訴我一件事情：所有的過程（這里的過程包括PRocedure和function）不要超過25行！因為這個長度的代碼看起來不會讓你頭暈，你會很容易了解這個過程要做的事情。
    那么怎么把原本在一個事件做的事情拆開呢？方法很多，我的經驗是模塊化。比如一個事件里要做很多不同的事情，那么就把不同的事情化為不同的子過程，然后在主過程里調用，主過程里大多數就是一些判斷和循環，不會出現具體的實現過程，這樣會生出很多的代碼段，但是會讓你的注意力集中！
    原則：一個過程只做一件事情，并且做好它。
    參考：VCL的源代碼?？纯碫CL的源代碼，很少有超過25行的代碼段！

三、參數名
    記得當初學SDK的時候，我一看到匈牙利表示法就頭暈，太多了！記不住??！所以我恨那個發明者：）終于Delphi出現了，戴著鐐銬跳舞的日子過去了！在Delphi里，定義一個字符串用strDoSometing這樣的變量名是可笑的和不必要的。只要你的過程很短，不出現全局變量，就不需要這樣的前綴。比如：
procedure SubPro;
var
  i : byte;
  Width, Height : integer;
begin
  Width := GetWidth;
  Height := GetHeight;
  for i:=0 to 9 do
  begin
    DrawThread := TDrawThread.Create;
    DrawThread.Width := Width;
    DrawThread.Height := Height;
    DrawThread.Start;
  end;
end;
    我想這樣的代碼段雖然沒有注釋，也很容易知道他要做的事情。所以，請去掉所有的前綴和下劃線，Delphi的程序不需要這些！我們的參數名只要動詞+名詞就可以，只要說明這個參數的作用就可以，多余的東西我們不要，簡單就是美，Pascal的好處就在于代碼像在說話，而不是讀天書，你的腦袋里是怎么想的，代碼就是什么樣子的。優美、簡單，這是Pascal的好處，請遵守！
    原則：簡單就是美！

四、子窗口
    很多人在調用子窗口的時候是直接對子窗口里的控件操作的，比如：
  if SetAlarmParamDlg.ShowModal = MrOK then
  begin
    AlarmTimes := StrToInt(SetAlarmParamDlg.Edit1.Text);
    AlarmArea  := SetAlarmParamDlg.SpinEdit1.Value;
  end;
    天，假如明天用戶覺得你用的Edit或者SpinEdit的樣子難看，換了一個漂亮的控件，你怎么辦？不但要修改子窗口的代碼，還要修改主窗體的代碼。一兩個子窗口的程序當然不會讓你痛苦，假如是一個有二十多個子窗體的程序呢？花一天的時間，原因卻只是因為換了一個控件！為什么不換一個方法？把要用的參數用屬性表示，你會少寫無數的代碼。
// 主窗體
  if SetAlarmParamDlg.ShowModal = MrOK then
  begin
    AlarmTimes := SetAlarmParamDlg.AlarmTimes;
    AlarmArea  := SetAlarmParamDlg.AlarmArea;
  end;

// 子窗體
interface
private
  FAlarmTimes : integer;
  FAlarmArea : integer;
published
  property AlarmTimes : integer read FAlarmTimes write FAlarmTimes;
  property AlarmArea : integer read FAlarmArea write FAlarmArea;

implementation
...
  FAlarmTimes := StrToInt(Edit1.Text);
  FAlarmArea := SpinEdit1.Value;
 
  ModalResult := MrOK;
...

    只要這樣堅持下來，你會發現好處大大的，一個子窗口只做他自己的事情，主窗口和他的交互是通過屬性來做的，只要接口不變，子窗口的修改不會影響到主窗口的代碼，不管子窗口的樣子怎么變換，控件怎么更換，代碼怎么修改，整個程序都還是老樣子，只是界面變了而已。
    原則：模塊化你的子窗口，窗口也是類，類之間怎么通信，窗口之間就應該怎么通信