一名Delphi程式設計師的開發習慣(非技術問題) (轉)
一名員的開發習慣(非技術問題):namespace prefix = o ns = "urn:schemas--com::office" />
作者: Musicwind®
建立時間:2001-09-26
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
有關開發習慣的一些想法,如鯁在喉,不吐不快。究其發貼動機,當然不排除有騙取參與分的可能,但另一方面,也希望能給同行(念Xing)者提供一些建議,或者參考(希望不是誤人子弟)。同時,也希望各位能夠就我的這些陋習,發表一點看法,給出批評和指正的意見。謝謝。
一.建立工程目錄
首先,第一步要做的,當然是給新專案建一個單獨的目錄(別笑)。目錄名稱與專案名稱同名,或者另取一個也可,只要清楚、簡練。然後,在此目錄中建立以下各個目錄:
<>:用來存放Delphi源程式中的”.Dpr”,”.Pas”,”.Dfm”等;
二.設定工程選項
在Delphi中建立一個新的工程,將此工程儲存到Source目錄中,同時:
a. 選一個耐看的,與專案有些聯絡的圖示作為這個工程的圖示。當然,這個圖示可能只是臨時用用的,但是總要比Delphi預設的那個難看的要好才行,要不然,怎麼對得起自己?
b. 將Project Options -> Directories/Conditionals頁面中的Output Directory設定為Bin目錄;
c. 將Unit output Directory設定為Dcu目錄。
三.新增常量單元
新增一個新的Unit,另存為“unt Consts.Pas”,用來儲存工程中用到的常量。
四.有關窗體(Form)及單元(Unit)
按照匈牙利命名法則給Form命名,則一個用來登入的窗體可以命名為’FrmLogin’,而其單元名可以為’untLogin’。通常,兩個對應的Form和Unit的名稱在除去’Frm’或’unt’的縮寫後應當保持一致。
在Unit的頭部新增本單元的註釋,註釋的格式可以參照Delphi的原始碼,但是至少應當包含以下幾項:功能描述;作者;版權;建立時間;最後修改時間;修改歷史等等。
將新建立好的Form的Caption設定為該Form類的名稱,而不是使用Delphi預設的。比如,將Form1更名為FrmLogin後,此時我們獲得了TFrmLogin這個新的窗體類,並且Delphi自動將窗體的Caption為’FrmLogin’。依我看,該Caption應當為’TFrmLogin’才是,因為我們在設計的是一個窗體類TFrmLogin,而不是僅僅對FrmLogin進行操作。
向TFrmLogin這樣功能明確的窗體類,許多人都有在設計期就將其Caption設定為諸如“操作員登入”這種名稱的習慣。我的習慣是,象“操作員登入”這樣的常量,通常存放在untConsts.Pas中,用ResourceString來定義,或者用Const來定義。至於窗體的Caption的命名,應當屬於執行期的工作。所以,我往往在TForm.OnCreate事件觸發之時才對Caption進行操作,比如:
procedure TFrmLogin.FormCreate(Sender: T);
begin
Caption := csLoginTitle;
....
end;
五.關於Format的使用
有iYear,iMonth,iDay三個資料,要顯示諸如“生日:1976/3/18”這樣的資訊,你通常怎麼做?使用s := ‘生日:’+IntToStr(iYear)+’.’+IntToStr(iMonth)+’.’+IntToStr(iDay); 嗎?這樣實在是太累了。我的習慣是,在untConsts.Pas中增加一個常量csBirthDayFormat = ‘生日:%d/%d/%d’來儲存顯示格式,然後使用s := Format(csBirthDayFormat, [iYear, iMonth, iDay]);這樣的語句完成資料的拼裝。這麼做的好處顯而易見,那就是你只需在一個地方維護資料的顯示格式。
Format函式功能強大,我對它很是推崇,你呢?
六.關於登錄檔或者Ini檔案的
原先訪問登錄檔我通常使用TRegistry,而訪問Ini檔案通常使用TIniFile。這兩個類的使用方法各不相同,因此想要使用相同的程式碼既能訪問登錄檔又能訪問Ini檔案幾乎是不可能的。真頭疼啊!
終於我發現了救星!那就是TRegistryIniFile類。檢視Registry單元,我們發現,TRegistryIniFile繼承自TCusomIniFile。而TIniFile也是繼承於TCusomIniFile。因此,使用抽象類TCusomIniFile來實現對登錄檔或者Ini檔案的訪問便是一舉兩得了。比如:
var
csmIniFile: TCusomIniFile;
begin
if blUseIniFile then//如果使用Ini檔案
csmIniFile:= TIniFile.Create(csKey)
else
csmIniFile:= TRegistryIniFile.Create(csRootKey);
//接著就可以使用csmIniFile對Ini檔案進行訪問,
//或者用類似訪問Ini檔案的方式訪問登錄檔。
七.關於TStream流以及TFileStream,TMemoryStream等等
TFileStream和TMemoryStream都繼承自抽象類TStream,這意味著我們可以使用一套程式碼完成對檔案和的存取操作。因此,定義一些介面的時候,我往往傾向於將引數的型別定義為抽象類,而不是具體類。比如,要完成儲存功能的一個函式,定義成
function Save(AStream: TStream): Boolean;
就比定義成
function Save(AStream: TFileStream): Boolean;
要靈活的多。
前一個定義是具有前瞻性的,因為它可以適用於以後可能出現的新型態的流。而後一個定義只適用於TFileStream這種流(當然包括TFileStream的子類),呆板多了。
我的習慣:如果存在抽象類,那麼儘量將引數定義為抽象類的型別,畢竟,我們無法預見未來。
八.多使用TAction
Delphi 4以後引入了Action的概念,並且在Standard欄中增加TActionList元件。使用Action的好處是,狀態同步的煩惱從此一掃而空!
/develop/my_article.?author=Musicwind">更多文章
Musicwind®@HangZhou.Zj.China
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10748419/viewspace-1007122/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 程式設計師的10個好習慣程式設計師
- 高效程式設計師的七個習慣程式設計師
- 谷歌程式設計師有哪些高效的程式設計習慣?谷歌程式設計師
- Java程式設計師必讀:最新流行的Java開發程式設計技術Java程式設計師
- 分享 程式碼大全 節選 -- 程式設計師的習慣程式設計師
- 怎麼樣學好python技術當一名程式設計師Python程式設計師
- 高效程式設計師的45個習慣-敏捷開發修煉之道(讀後感)程式設計師敏捷
- 一名測試工程師的日常習慣工程師
- 好程式設計師Java教程分享面試中Spring的技術問題程式設計師Java面試Spring
- 程式設計師必讀的30本非技術書(文末福利)程式設計師
- 一名小白程式設計師的實習生生活程式設計師
- 頂尖程式設計師的10個優良習慣程式設計師
- 資深程式設計師的16個優良習慣!!!程式設計師
- 10個程式設計好習慣:優秀程式設計師的經驗分享程式設計師
- 程式設計好習慣程式設計
- 又一名倒下的程式設計師! - 程式設計師健康指南程式設計師
- java程式設計師進階:Redis分散式技術問題集錦Java程式設計師Redis分散式
- 程式設計師的技術遺產程式設計師
- 自學前端程式設計非技術性問題及解決辦法和學習方法總結前端程式設計
- 高效程式設計師的45個習慣 讀書筆記程式設計師筆記
- 程式設計師的35個壞習慣,你有幾條?程式設計師
- 作為一名Java程式設計師一定要不斷關注學習最前沿的技術Java程式設計師
- Java外包程式設計師的技術出路Java程式設計師
- 程式設計師技術入股的那些坑程式設計師
- 美女程式設計師觀點:程式設計師最重要的非程式設計技巧程式設計師
- Java程式設計師總結出的技術以及學習方法Java程式設計師
- 面試常見的非技術問題面試
- Java開發需要掌握哪些技術?Java程式設計師必備技能Java程式設計師
- 好程式設計師技術文件HTML5開發中的javascript閉包程式設計師HTMLJavaScript
- 一名優秀的程式設計師應該向誰提問程式設計師
- 2020,要想成為一名專業的web前端開發程式設計師,需要學習什麼?Web前端程式設計師
- 程式設計師、技術主管和架構師程式設計師架構
- 年薪80萬難求一名AI程式設計師,技術革新世界已到來!!AI程式設計師
- 程式設計師,如何從開發轉型做架構師?程式設計師架構
- Python程式設計的16個壞習慣Python程式設計
- FFmpeg開發筆記(四十七)寒冬下安卓程式設計師的幾個技術轉型發展方向筆記安卓程式設計師
- 好程式設計師Java培訓Java程式設計師必學技術程式設計師Java
- 一個引發程式設計師們幹架的問題程式設計師
- 讓程式設計師崩潰的瞬間(非程式設計師勿入)程式設計師