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

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

三、參數(shù)名
    記得當(dāng)初學(xué)SDK的時候，我一看到匈牙利表示法就頭暈，太多了！記不住啊！所以我恨那個發(fā)明者：）終于Delphi出現(xiàn)了，戴著鐐銬跳舞的日子過去了！在Delphi里，定義一個字符串用strDoSometing這樣的變量名是可笑的和不必要的。只要你的過程很短，不出現(xiàn)全局變量，就不需要這樣的前綴。比如：
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的程序不需要這些！我們的參數(shù)名只要動詞+名詞就可以，只要說明這個參數(shù)的作用就可以，多余的東西我們不要，簡單就是美，Pascal的好處就在于代碼像在說話，而不是讀天書，你的腦袋里是怎么想的，代碼就是什么樣子的。優(yōu)美、簡單，這是Pascal的好處，請遵守！
    原則：簡單就是美！

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

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