一、老生長談
    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è)計不出漂亮的界面，只是花費的時間太長，不值得。
    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的源代碼?？纯碫CL的源代碼，很少有超過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)該怎么通信

一、關(guān)于界面
  界面對于一個程序，仿佛就是容貌對于一個人，重要性是不言而喻的。
  一個程序的界面做的很漂亮是很好，但是如果界面不能很好的反映功能，那再漂亮的界面都是垃圾一堆，這方面我是有體會的，當(dāng)你的大部分精力全放在如何

做一個漂亮的界面的時候，災(zāi)難就降臨了，你將永遠(yuǎn)無法把程序的功能做好！如果想把程序做好，就不要考慮漂亮的界面，等到功能全部實現(xiàn)的時候，界面自然

就會出現(xiàn)，到時候美化也不遲。
  這個問題上，Delphi的程序員可能遇到的最多，因為滿天飛的都是漂亮的控件，這個也好，那個也好，不用真是可惜，于是找個一堆控件，一個個的試驗過來

，功能全然不顧。其實用戶用一個軟件，不是因為界面漂亮，而是因為功能強。即使是在DOS窗口下跑的程序，只要功能強，用戶照樣會津津有味的使用，如果功

能弱的一塌糊涂，即使界面做成無比酷，最后的命運也是被刪除。所以，寫一個軟件的時候，請首先從功能入手，而不是界面！
  那么是不是不用考慮漂亮的界面呢？也不是。終究漂亮的界面是很吸引眼球的，但是要是按照我的意思，先弄個普通的界面，最后美化，會造成一個問題，就

是要修改很多代碼，比如：

procedure TMainForm.Button1Click(Sender : TObject)
begin
  FWidth := StrToInt(Edit1.Text);
  FHeight := StrToInt(Edit2.Text);
  FScreenSize := FWidth * FHeight;
end;

  上面的代碼運行的時候是沒有什么問題的，但是一旦你換了一個Edit控件，或者是只是換了Edit的名字，工作量就出來了，一個兩個的變化還沒有問題，假如

這個Edit1.Text在代碼里出現(xiàn)了100多個地方呢？怎么辦？我的方法是把程序的界面和功能分開！代碼盡量不要和具體的控件相關(guān)聯(lián)。如下：
procedure TMainForm.SetParam(const Width, Height : string);
begin
  FWidth := StrToInt(Width);
  FHeight := StrToInt(Height);
  FScreen := FWidth * FHeight;
end;
procedure TMainForm.Button1Click(Sender : TObject)
begin
  SetParam(Edit1.Text, Edit2.Text);
end;
  這個例子有點極端，好像是畫蛇添足，但是當(dāng)你大量的修改控件或者更換控件名字的時候，作用就顯示出來了。到你最后想美化界面的時候，修改代碼的工作

量會減輕很多。因為只要傳入的參數(shù)更換一次就可以，而不是在無數(shù)的地方進行修改。
  原則：界面和實現(xiàn)分開

二、全局變量
  不要使用全局變量?。?！即使設(shè)定的全局變量你認(rèn)為一萬年也不會變，也不要使用，因為說不定那天修改了一個功能，這個全局變量就要拆成兩個變量了，那

么問題就會出現(xiàn)，還是通過參數(shù)傳遞吧。還是來個例子：
//main
const
  ShowWidth = 384;
  ShowHeight = 288;
...

// SetParamDlg 子窗口
  SpinEdit1.Value := MainForm.ShowWidth;
  SpinEdit2.Value := MainForm.ShowHeight;

  上面的代碼工作的不錯，但是假如有一天客戶說我要分辨率可變，怎么辦？在const里重新加入ShowWidth1、ShowWidth2、、、？最后const的體積會越來越大

，查const的時候會累死你，那換一種方法：
//main
function ReadWidth : integer;
function ReadHeigth : integer;

SetParamDlg.Width := ReadWidth;
SetParamDlg.Height := ReadHeight;

//SetParamDlg
  SpinEdit1.Value := FWidth;
  SpinEdit2.Value := FHeight;

  是不是比較好一點？
  原則：盡量在一開始設(shè)計的時候把所有看起來目前不會變化的參數(shù)也做成動態(tài)的。

三、一個小問題
  這是我在一個網(wǎng)站上看到的，比較有意思，而且感覺很容易犯，這里就抄襲一下了，不過這只是編程技巧，不是方法
function sum(a : array of word; count : word) : longword;
var
 i : word;
begin
 result := 0;
 for i := 0 to count - 1 do inc(result, a[ i ]);
end;

  上面的代碼有問題么？乍看是沒有問題，但是說不定什么時候他就當(dāng)?shù)袅?。為什么？因為Count是個WORD，假如傳入?yún)?shù)的時候Count=0會發(fā)生什么事情呢？對

了，WORD翻轉(zhuǎn)了，那就等他循環(huán)FFFF次吧：）所以請注意無符號類型的操作！

累了，自己都感覺沒寫好，休息ing，歡迎磚頭，歡迎高手來發(fā)表意見....