上午看了一個高手的blog，他上面寫到有關(guān)程序，我覺得寫的很不錯，貼上來，大家一起勉勵一下
??????1. 學(xué)習(xí)應(yīng)該從基礎(chǔ)打起，不要一開始就嘗試最高深的技術(shù)。 2. 每看一本書，不要說這章我以前學(xué)習(xí)過了，也掌握的很好，因此我可以跳過這一章看更重要的了。
3. 對于作業(yè)，遇到不會的盡量不要立刻向別人請教。如果實在解決不了的問題，可以先完成你會的，然后把一些特別的難點提煉出來，向高手請教。不要指望書本和行家能幫你解決一切問題，因為并不是所有問題都能由別人教給你。
4. 向別人請教問題應(yīng)該把問題說明白。對于錯誤提示信息應(yīng)該原樣提供出來，不要按自己理解的信息提供。因為既然你自己做不了，說明你理解一般都有問題。
5. 問問題最好能帶代碼。
6. 不要說“編譯通過，可是運(yùn)行時..."，因為編譯錯誤和運(yùn)行錯誤可能根本沒有關(guān)系。一般來說，編譯是語法問題，而運(yùn)行是邏輯問題。
7. 書看千遍不如做程序一遍，應(yīng)該盡量嘗試去寫程序。
8. 做程序千個不如做好程序一個。應(yīng)該盡量完善你現(xiàn)在做的程序，而不要不斷開新的計劃，而每個計劃都虎頭蛇尾。
9. 要想到你不是一個人寫程序，而是和大家一起寫程序。
10. 高深的技巧雖然顯示了高深的本領(lǐng)，但是對于合作往往是有害的，應(yīng)該盡量寫出簡單易讀的代碼。
11. 編制程序應(yīng)該盡量做到自注釋，即代碼本身一讀就懂，好象自己在說明自己的邏輯一樣。
12. 復(fù)雜的代碼如果實在做不到自注釋，應(yīng)該給出適量的注釋。
13. 注釋在修改代碼的時候應(yīng)該相應(yīng)修改，不能用陳舊的注釋去誤導(dǎo)別人。
14. 代碼應(yīng)該盡量可重用，相同功能的代碼應(yīng)該由相同的函數(shù)完成，重要函數(shù)應(yīng)該給出調(diào)試信息，以便調(diào)試時及早發(fā)現(xiàn)問題。
15. 應(yīng)該盡量寫小函數(shù)，每個函數(shù)盡量不要超過40行或者更少。這樣不用滾動屏幕也許就可以讀完整個函數(shù)。
16. 對于switch語句，盡量不要有過多的分支，如果分支太多，可以考慮用跳轉(zhuǎn)表。
17. 盡量少使用一些有爭議的語句，如goto和三目運(yùn)算符，既然有爭議，它肯定有一定的缺點。
18. 對于goto，許多工程師技術(shù)高到可以合理使用，而不至于導(dǎo)致問題。但是你的程序并不一定給你同水平的人看和修改，他們可不能保證合理的讀和修改這些相關(guān)代碼。
19. 代碼編寫時應(yīng)該有一定的格式，其基本要求是對理解代碼有一定幫助。
20. 如果數(shù)據(jù)是多個模塊共有的，應(yīng)該提供一個封裝的類來管理它，并提供一個合適的接口給各個模塊。這樣，如果數(shù)據(jù)內(nèi)容有重大修改，則只要接口不變，基本上可以保證程序不要很復(fù)雜的修改。
21. 應(yīng)該盡量考慮到數(shù)據(jù)的并發(fā)控制。
22. 數(shù)據(jù)的并發(fā)控制應(yīng)該封裝在接口內(nèi)，而不要暴露給其他模塊，這樣可以減少因為并發(fā)原因?qū)е碌某绦蛩梨i。
23. 數(shù)據(jù)本身結(jié)構(gòu)不可以太復(fù)雜。應(yīng)該盡量把不相關(guān)的數(shù)據(jù)分割成為兩組數(shù)據(jù)。
24. 對于數(shù)據(jù)量比較大的情況，應(yīng)該考慮數(shù)據(jù)庫。
25. 數(shù)據(jù)庫接口應(yīng)該采用標(biāo)準(zhǔn)ODBC或者ADO接口，盡量不要根據(jù)實際數(shù)據(jù)庫DBMS提供的接口來處理，因為你可能在實際使用中更換DBMS。
26. 小的數(shù)據(jù)可以考慮文件，文件路徑應(yīng)該必須設(shè)計成相對路徑。
27. 在一個函數(shù)中，應(yīng)該盡量打開文件后使用完后立刻關(guān)閉，這樣其他程序可能使用文件。
28. 不要嘗試把文件全部讀到內(nèi)存中，應(yīng)該分次處理大文件。
29. 編寫程序應(yīng)該提供相關(guān)的測試程序，以提供測試手段。
30. 應(yīng)該考慮代碼、函數(shù)的使用情況，不要超越函數(shù)可以使用的范圍使用之。
Trackback:http://blog.csdn.net/hotsummerghost/archive/2005/07/03/411231.aspx