如何編寫高品質的易語言代碼？

如何編寫高品質的易語言代碼？
如何編寫高品質的易語言代碼？下面參考了塵虛緣的意見作了一些修改。 什麼是一個高效的軟體？一個高效的軟體不僅應該比實現同樣功能的軟體運行得更快，還應該消耗更少的系統資源。程式的時間效率是指運行速度，空間效率是指程式佔用記憶體或者外存的狀況。另外程式的效率我們也可以分為全局效率和局部效率。全局效率是指站在整個系統的角度上考慮的效率，局部效率是指站在模組或函數角度上考慮的效率。 1. 使用整數和長整數 　　提高代碼運行速度最簡單的方法莫過於使用正確的資料類型了。也許你不相信，但是正確地選擇資料類型可以大幅度提升代碼的性能。在大多數情況下，程式師可以將短整數型、小數型和雙精度小數型的變數替換為整數（Integer）或長整數（Long）類型的變數，因為易語言處理整數和長整數的能力遠遠高於處理其他幾種資料類型。　　在大多數情況下，程式師選擇使用小數型或雙精度小數型的原因是因為它們能夠保存小數。但是小數也可以保存在整數類型的變數中。例如程式中約定有三位元小數，那麼只需要將保存在整數型變數中的數值除以1000就可以得到結果。根據我的經驗，使用整數和長整數替代短整數型、小數型和雙精度小數型後，代碼的運行速度可以提高將近10倍。 但是我們也不要老是強調使用使用整數和長整數，因為在程式中資料類型的定義還牽涉一個關鍵的問題,就是資料的安全,頻繁而無規範地定義 資料類型會使演算法出現漏洞,是資料的安全和臨界判斷有問題.對財務和工程計算而言,小數點的精度是很敏感的資料,只能用雙精度資料來規範.另外, 換成整型也會導致程式可讀性急劇下降. 2. 避免使用通用型資料 　　通用型的變數需要16個位元組的空間來保存資料，而一個整數（Integer）只需要2個位元組。通常使用通用型變數的目的是為了減少設計的工作量和代碼量，也有的程式師圖個省事而使用它。但是如果一個軟體經過了嚴格設計和按照規範編碼的話，完全可以避免使用變體類型。 3. 儘量避免使用屬性 　　在平時的代碼中，最常見的比較低效的代碼就是在可以使用變數的情況下，反復使用屬性（Property），尤其是在迴圈中。要知道存取變數的速度是存取屬性的速度的20倍左右。下面這段代碼是很多程式師在程式中會使用到的：容器名： 數值 類型：整數型容器名： 容器 類型：整數型 計次迴圈首（7，容器） 文本1.內容 = 文本1.內容 + #換行符 + 到文本（（數值×容器））計次迴圈尾（） 　　下面這段代碼的執行速度是上面代碼的20倍。 容器名： 數值 類型：整數型容器名： 容器 類型：整數型容器名： 文本 類型：文本型 文本 = 文本1.內容 計次迴圈首（7，容器）文本 = 文本 + #換行符 + 到文本（（數值×容器））計次迴圈尾（）文本1.內容 = 文本另外要注意，這個涉及一個編程思路， 用屬性當變數的作法大多數情況可以簡化演算法。所以有時候也不能一味強調用變數代替屬性。 6. 避免調用很短的副程式 　　調用只有幾行代碼的副程式也是不經濟的--調用副程式所花費的時間或許比執行副程式中的代碼需要更長的時間。在這種情況下，你可以把副程式中的代碼拷貝到原來調用副程式的地方。但是有時候小的副程式可能會被調用很多次而不是只有兩三次，這時就應該調用它。 7. 減少對子物件的引用 　　在易語言中，通過使用.來實現物件的引用。例如： 窗口1.編輯框1.內容 　　在上面的例子中，程式引用了兩個物件：窗口1和編輯框1。利用這種方法引用效率很低。但遺憾的是，沒有辦法可以避免它。我的“多媒體模組”就有這個缺點。 8. 檢查文本型資料是否為空 　　大多數易語言用戶在檢查文本型資料是否為空時會使用下面的方法： 如果 （文本1.內容 = "" ） 注釋： 執行操作 結束如果 　　很不幸，進行字串比較需要的處理量甚至比讀取屬性還要大。因此我建議大家使用下面的方法：如果 （到數值(文本1.內容) = 0 ） 注釋： 執行操作 結束如果 另一個不同的意見是：問題在於當文本字串為 "ABC"之類的非數值型時, 到數值("ABC")=0並不表示為空。文本比較的效率並不低,在底層演算法中,一般會直接比較長度才會繼續比較內容。 9. 使用陣列，而不是多個變數 　　當你有多個保存類似資料的變數時,可以考慮將他們用一個陣列代替。在易語言中，陣列是最高效的資料結構之一。 10. 儘量使用動態陣列，而不是靜態陣列 　　使用動態陣列對代碼的執行速度不會產生太大的影響，但是在某些情況下可以節約大量的資源。 11. 銷毀物件 　　無論編寫的是什麼軟體，程式師都需要考慮在用戶決定終止軟體運行後釋放軟體佔用的記憶體空間。但遺憾的是很多用戶對這一點好像並不是很在意。正確的做法是在退出程式前需要銷毀程式中使用的物件。例如：關閉資料庫：關閉（資料庫名稱）、全部關閉（），關閉打開（播放）的檔，關閉載入的圖片等。中止程式執行時應該要關閉打開的檔（包括資料庫檔、圖片檔等），但是視窗銷毀對銷毀視窗及視窗單元來說是自動的,已足夠做釋放用,在視窗內最好不要隨意銷毀視窗單元,可能會導致程式運行中的潛在的單元資料訪問而崩潰.只有在圖形buffer情況才需要經常銷毀。 12. 儘量使用內部副程式，減少易模組的數量 因為從易語言連接到一個外部物件需要耗費大量的CPU處理能力。每當你調用介面函數的時候，都會浪費大量的系統資源。 另外只有在易模組中的介面函數或變數被調用時，易語言才將易模組載入到記憶體中；當易語言應用程式退出時，才會從記憶體中卸載這些模組。如果代碼中只有一個模組，易語言就只會進行一次載入操作，這樣代碼的效率就得到了提高；反之如果代碼中有多個模組，易語言會進行多次載入操作，代碼的效率會降低。 13. 使用物件陣列 　　當設計用戶介面時，對於同樣類型的控制項，程式師應該儘量使用物件陣列。你可以做一個實驗：在視窗上添加100個圖片框，每個圖片框都有不同的名稱，運行程式。然後創建一個新的工程，同樣在視窗上添加100個圖片框，不過這一次使用物件陣列，運行程式，你可以注意到兩個程式載入時間上的差別。 也有人認為兩者從邏輯上看效率應該差不多。 14. 使用視窗單元“移動”方法 　　在改變物件的位置時，有些用戶喜歡使用“寬度”、“高度”、“頂邊”和“左邊”屬性。例如：按鈕1.寬度 = 100 按鈕1.高度 = 100 按鈕1.頂邊 = 0 按鈕1.左邊 = 0 　　實際上這樣做效率很低，因為程式修改了四個屬性，而且每次修改之後，視窗都會被重繪。正確的做法是使用Move方法： 按鈕1.移動（0,0,100,100） 15. 減少圖片的使用 　　圖片將佔用大量記憶體，而且處理圖片也需要佔用很多CPU資源。在軟體中，如果可能的話，可以考慮用背景色來替代圖片--當然這只是從技術人員的角度出發看這個問題。 但是如果為了優化程式介面，使用圖形換來的好處可能遠勝節約下的資源，否則就不會有XP,也不會有遊戲的進步了。 16. 編譯優化 易語言的程式編譯有三個選項：“編譯”、“獨立編譯”、“編譯生成安裝軟體”。優先使用的次序應該是“編譯生成安裝軟體”、“編譯”、“獨立編譯”，因為“獨立編譯”會將易語言系統中所有的支援函式庫都編譯進去，而“編譯生成安裝軟體”只選擇程式中必要的支援函式庫編譯。要脫離易語言環境也可以運行，就不要使用“編譯”而應用“編譯生成安裝軟體”或“獨立編譯”。總結：執行效率和程式可讀性永遠是對矛盾 ，兩者應該通盤考慮；資源佔用和程式易用性永遠是對矛盾，兩者也應該通盤考慮。基於此，下面探討一些提高程式的效率的規則。 【規則1】不要一味地追求程式的效率，應當在滿足正確性、可靠性、健壯性、可讀性等品質因素的前提下，設法提高程式的效率。 【規則2】以提高程式的全局效率為主，提高局部效率為輔。 【規則3】在優化程式的效率時，應當先找出限制效率的“瓶頸”，不要在無關緊要之處優化。【規則4】先優化資料結構和演算法，再優化執行代碼。先考慮某功能是否可以用函數（命令）來實現，如果找不到這樣的函數，再考慮用其他代碼實現。【規則5】有時候時間效率和空間效率可能對立，此時應當分析那個更重要，作出適當的折衷。例如多花費一些記憶體來提高性能。【規則6】不要在什麼時候都只追求緊湊的代碼，因為緊湊的代碼並不能產生高效的機器碼

大大 你好像發錯區了..
這邊是DELPHI區喔!!