程式設計中的一些感悟(收藏) (轉)

worldblog發表於2008-01-06
程式設計中的一些感悟(收藏) (轉)[@more@]

(羅恩發表於2002-10-29 8:16:01)

1)學習應該從基礎打起,不要一開始就嘗試最高深的技術。
2)每看一本書,不要說這章我以前學習過了,也掌握的很好,因此我可以跳過這一章看更重要的了。
3)對於作業,遇到不會的儘量不要立刻向別人請教。如果實在解決不了的問題,可以先完成你會的,然後把一些特別的難點提煉出來,向高手請教。
3)不要指望書本和行家能幫你解決一切問題,因為並不是所有問題都能由別人教給你。

4)向別人請教問題應該把問題說明白。對於錯誤提示資訊應該原樣提供出來,不要按自己理解的資訊提供。因為既然你自己做不了,說明你理解一般都有問題。
5)問問題最好能帶程式碼。
6)不要說“編譯透過,可是執行時...",因為編譯錯誤和執行錯誤可能根本沒有關係。一般來說,編譯是語法問題,而執行是邏輯問題。
7) 書看千遍不如做一遍,應該儘量嘗試去寫程式。
8)做程式千個不如做好程式一個。應該儘量完善你現在做的程式,而不要不斷開新的計劃,而每個計劃都虎頭蛇尾。


9)要想到你不是一個人寫程式,而是和大家一起寫程式。
10)高深的技巧雖然顯示了高深的本領,但是對於合作往往是有害的,應該儘量寫出簡單易讀的程式碼。
11)編制程式應該儘量做到自注釋,即程式碼本身一讀就懂,好象自己在說明自己的邏輯一樣。
12)複雜的程式碼如果實在做不到自注釋,應該給出適量的註釋。
13)註釋在修改程式碼的時候應該相應修改,不能用陳舊的註釋去誤導別人。
14)程式碼應該儘量可重用,相同功能的程式碼應該由相同的完成,重要函式應該給出資訊,以便除錯時及早發現問題。
15)應該儘量寫小函式,每個函式儘量不要超過40行或者更少。這樣不用滾動螢幕也許就可以讀完整個函式。
16)對於switch語句,儘量不要有過多的分支,如果分支太多,可以考慮用跳轉表。
17)儘量少使用一些有爭議的語句,如goto和三目運算子,既然有爭議,它肯定有一定的缺點。
18)對於goto,許多工程師技術高到可以合理使用,而不至於導致問題。但是你的程式並不一定給你同水平的人看和修改,他們可不能保證合理的讀和修改這些相關程式碼。
19)程式碼編寫時應該有一定的格式,其基本要求是對理解程式碼有一定幫助。
20)如果資料是多個模組共有的,應該提供一個封裝的類來管理它,並提供一個合適的介面給各個模組。這樣,如果資料內容有重大修改,則只要介面不變,基本上可以保證程式不要很複雜的修改。
21)應該儘量考慮到資料的併發控制。
22)資料的併發控制應該封裝在介面內,而不要暴露給其他模組,這樣可以減少因為併發原因導致的程式死鎖。
23)資料本身結構不可以太複雜。應該儘量把不相關的資料分割成為兩組資料。
24)對於資料量比較大的情況,應該考慮。
25)資料庫介面應該採用標準OC或者ADO介面,儘量不要根據實際資料庫DBMS提供的介面來處理,因為你可能在實際使用中更換DBMS。
26)小的資料可以考慮,檔案路徑應該必須設計成相對路徑。
27)在一個函式中,應該儘量開啟檔案後使用完後立刻關閉,這樣其他程式可能使用檔案。
28)不要嘗試把檔案全部讀到中,應該分次處理大檔案。
29)編寫程式應該提供相關的測試程式,以提供測試手段。
30)應該考慮程式碼、函式的使用情況,不要超越函式可以使用的範圍使用之。
隨便寫了這麼點,呵呵,應該是比較凌亂的,也不完全,希望大家不要見笑。

 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-996679/,如需轉載,請註明出處,否則將追究法律責任。

相關文章