程序設計中的一些感悟

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）數據庫接口應該採用標準ODBC或者ADO接口，儘量不要根據實際數據庫DBMS提供的接口來處理，因爲你可能在實際使用中更換DBMS。

26）小的數據可以考慮文件，文件路徑應該必須設計成相對路徑。

27）在一個函數中，應該儘量打開文件後使用完後立刻關閉，這樣其他程序可能使用文件。

28）不要嘗試把文件全部讀到內存中，應該分次處理大文件。

29）編寫程序應該提供相關的測試程序，以提供測試手段。 polo shirts

30）應該考慮代碼、函數的使用情況，不要超越函數可以使用的範圍使用之