寫好程式碼的10個祕密

　　先給大家看一段據說是史上最強的程式，這段程式是1997年世界程式設計大賽的一等獎作品，完整的程式碼下載，把程式碼複製貼上到cmd的debug命令中，回車看到效果。這個程式執行後將是一個3D的且伴隨著音樂的動畫。震撼吧！

　　複製貼上過程：把下載的程式文字檔案內容複製下->點選 開始->執行->輸入cmd回車->輸入debug 回車->把指標放在視窗標題欄上右擊->點選貼上->貼上完成後按回車，
然後不要動，你就看見程式的執行結果了 ，是一個3D動畫， 按esc鍵就退出了。

　　是不是從事軟體開發的人員都希望成為這樣的武林高手呢？然而真要是用這樣的高手來設計、編寫我們的產品程式碼，恐怕某一天，我們什麼都不用幹了，只能人手一本機器程式碼，一句一句進行翻譯了；那麼對於軟體產品開發而言，如何寫好程式碼呢？一流的軟體產品的程式碼具備哪些特徵呢？

　　一流程式碼的特徵

　　1、穩定可靠（Robustness）

　　程式碼寫出來以後，一定要能夠執行得非常好，非常穩定可靠。在現今的IT行業，軟體產品都是是24*7，即要保證系統一天24小時，一星期7天中都可以無間斷的正常執行。比如我們百度的搜尋引擎系統，比如我們的通訊系統，等等。到了產品開發後期，大部分的成本都將投入到產品穩定性的提高。

　　2、可維護且簡潔（Maintainable and Simple Code）

　　在寫程式碼時，首先要考慮的是：寫出來的程式碼不但要自己可以讀懂，而且我們的同事、測試工程師都可能要修改這些程式碼，對其進行增減。如果程式碼很複雜，不容易讀懂，如程式中的遞迴一大堆、程式不知何時或從何地跳出，則會使程式的可維護性和簡潔性降低。所以必要的註釋、統一的程式設計規範等都是非常重要的。

　　3、高效（Fast）

　　在軟體行業中效率是非常重要的，比如搜尋引擎。有些軟體的搜尋效率就不高，搜尋過程特別緩慢，讓人難以接受。當然這裡面有一個頻寬的問題，但是程式效率不高也是一個重要的原因。而實際上程式的效率提高，有時候很簡單，並沒有什麼神祕之處，如使用陣列索引時候，可以用指標方式而不使用陣列下標；陣列的空間定義應該定義為2的N次冪等等。

　　4、簡短（Small）

　　這方面大家的感受可能不是很深，但是我的感受是很深的。配置過PSTN程控交換機、路由器、VoIP閘道器裝置的人都知道，這些裝置的軟體都是從PC機通過網口或串列埠下載到這些裝置的Flash上（類似PC機的BIOS）再通過裝置上的CPU啟動。如果程式寫的很羅嗦，隨著特性不斷增加，程式規模將變大的巨大，Flash空間告急、記憶體告急、下載升級變的不可忍受，等等，帶來的就是成本不斷增加，利潤不斷下降。

　　5、共享性（Reusable）

　　如果做大型產品開發，程式的共享性也是非常重要的。我們產品有那麼多開發人員，如果每一個人都自己定義字串、連結串列等資料結構，那麼開發效率就會降低，我們的產品恐怕到今天也不能出臺。我所說的“共享”不是指將別人的程式碼複製到自己的程式碼中，而是指直接呼叫別人的程式碼，拿來即可用。這一方面可以減少程式碼的冗餘性，另一方面可以增強程式碼的可維護性。如果別人的程式碼裡有Bug，只需修改他的程式碼，而呼叫此程式碼的程式不用進行任何修改就可以達到同步。這同時要求我們在設計的時候，如何考慮系統的內聚和耦合的問題。

　　6、可測試性（Testable）

　　我們的產品開發裡，除了軟體開發人員，還有一部分工程師負責軟體測試。軟體測試人員會將開發程式碼拿來，一行一行地執行，看程式執行是否有錯。如果軟體開發人員的程式碼不可測試，那測試工程師就沒有辦法進行工作。因此可測試性在大型軟體開發裡是很重要的一點。可測試性有時候與可維護性是遙相呼應的，一個具有好的可測試性和可維護性的程式碼，測試人員可以根據開發提供的維護手冊、debug資訊手冊等就可以判斷出程式出錯在哪個模組。

　　7、可移植性（Portable）

　　可移植性是指程式寫出來以後，不僅在windows 2000裡可以執行，在NT/9X下可以執行，而且在Linux甚至Macintosh等系統下都可以執行。所有這些特性都是一流程式碼所具備的特性。但是其中有些特性是會有衝突的。比如高效性，程式寫的效率很高，就可能變得很複雜，犧牲的就是簡潔。好的程式碼要在這些特性中取得平衡。

　　寫好程式碼的10個祕密

　　1、百家之長歸我所有（Follow Basic Coding Style）

　　其實寫程式碼的方式有很多，每個人都有自己的風格，但是眾多的風格中總有一些共性的、基本的寫程式碼的風格，如為程式寫註釋、程式碼對齊，等等。是不是程式設計規範？對就是程式設計規範。

　　2、取個好名字（Use Naming Conventions）

　　取個好的函式名、變數名，最好按照一定的規則起名。還是程式設計規範。

　　3、凌波微步，未必摔跤（Evil goto’s?Maybe Not…）

　　這裡我用“凌波微步”來形容goto語句。通常，goto語句使程式跳來跳去，不容易讀，而且不能優化，但是在某種情況下，goto語句反而可以增強程式的可讀性。Just go ahead，not go back。

　　4、先發制人，後發制於人（Practic Defensive Coding）

　　Defensive Coding指一些可能會出錯的情況，如變數的初始化等，要考慮到出現錯誤情況下的處理策略。測試時要多執行幾個執行緒。有些程式在一個線城下執行是正常的，但是在多個執行緒並行執行時就會出現問題；而有些程式在一個CPU下執行幾個執行緒是正常的，但是在多個CPU下執行時就會出現問題，因為單CPU執行執行緒只是狹義的並行，多CPU一起執行程式，才是真正的並行運算。

　　5、見招拆招，滴水不漏（Handle The Error Cases：They Will Occur！）

　　這裡的Error Case（錯誤情況），是指那些不易重視的錯誤。如果不對Error Case進行處理，程式在多數情況下不會出錯，但是一旦出現異常，程式就會崩潰。 6、熟習劍法刀術，所向無敵（Learn Win32 API Seriously）

　　用“劍法刀術”來形容一些API是因為它們都是經過了很多優秀開發人員的不斷開發、測試，其效率很高，而且簡潔易懂，希望大家能掌握它，熟悉它，使用它。是不是象我們的ULIB。

　　7、雙手互搏，無堅不摧（Test,but don’t stop there）

　　這裡的測試不是指別人來測試你的程式碼，而是指自己去測試。因為你是寫程式碼的原作者，對程式碼的瞭解最深，別人不可能比你更瞭解，所以你自己在測試時，可以很好地去測試哪些邊界條件，以及一些意向不到的情況。

　　8、活用斷言（Use,don’t abuse,assertions）

　　斷言（assertion）是個很好的除錯工具和方法，希望大家能多用斷言，但是並不是所有的情況下都可以用到斷言。有些情況使用斷言反而不合適。

　　9、草木皆兵，不可大意（Avoid Assumptions）

　　是指在寫程式碼時，要小心一些輸入的情況，比如輸入檔案、TCP的sockets、函式的引數等等，不要認為使用我們的API的使用者都知道什麼是正確的、什麼是錯的，也就是說一定要考慮到對外介面的出錯處理問題。

　　10、最高境界、無招勝有招（Stop writing so much code）

　　意思就是說盡量避免寫太多的程式碼，寫的越多，出錯的機會也越多。最好能重用別人開放的介面函式或直接呼叫別人的api。