《微軟C編程精粹》閱讀筆記

        我的以爲讀書有三個階段。第一個階段是讀書前的已有的認知。第二個階段是通讀一本書後get 到的東西。最後也是對於一本好書最重要的就是精讀後改變本身已有認知，提升自身能力。最後一個階段是對於一本好書本必須經歷的階段，這個階段付出時間成本很高但也最有養分，此種感受「妙趣橫生」，是一種昇華，對於一個執着於日日精進的工程技術人員來講這就是「求道」。

        對於如何編寫無錯代碼這個問題？若是能夠獲得這個問題的答案，能夠帶來巨大的利益，因此這個問題具備極大的吸引力！這個問題也困擾每個從業人員。通過各類碰壁或項目的煎熬後，咱們完全的失望了。得出一個結論：只要是人就必定會常常出錯，想寫一個0bug的程序幾乎是不可能的。這個答案彷佛是正確的，但這個答案對於咱們面對項目交付時間帶來的焦慮和壓力沒有一點做用。面對現實的巨大需求，咱們必需要想出對策並付諸於行動，而後咱們的測試小夥伴的隊伍愈來愈龐大，而後咱們的程序員和測試成爲了「天敵」。最後咱們仍是走偏了，這些無非是把一個無解的問題上升到哲學的無聊把戲。想要編寫無錯作好的方法就是把防錯放在第一位。但這個放錯方式確定不是用測試來防錯這種被動模式，咱們追求一種主動防錯模式。

         通讀這本《微軟C編程精粹》後我大概有了一個解決辦法。雖不能寫出「原教旨」般的0錯誤，但這個辦法確實能夠解決問題，給咱們帶來高效的帶來商用版本。這個也是無限逼近獲得的最優解了。寫出無錯代碼須要態度和追求。把態度擺好，代碼是本身寫的，查錯也是本身的主要責任。追求儘量早的查出錯誤，並且在差錯時不該該依賴其餘人。習慣這些，你雖然不能保證必定能夠寫出無錯代碼，當你確實是在正確的道路上，必然有個不錯的收穫。

      「大事必作於細」，既然知道是正確的道路，我必然精讀下去。獲得具體的措施。態度是本書的結尾。若是對於做者全部的建議，咱們作但持懷疑態度和繼續使用之前的編程方法，想寫出無錯代碼必然困難重重，必定會像管理不善的球隊輸多贏少。咱們做爲專業的程序員，測試必不可少，就像大廈的施工不可能沒有外面結實的腳手架保護同樣。在忙於應對項目問題的時候常常擡起頭看看遠方，想一想爲何會出錯，如何從源頭杜絕錯誤的發生。本書主要從七個方面作了詳細的建議，我也從七個方面寫下個人感覺.

1、對於和咱們緊密相關的工具，咱們不能無論不顧，若是有條件能夠定製改造，編譯的時候打開儘可能多的告警。

2、編譯器查出的只是小部分錯誤，要學會使用assert查錯，對於不清楚的斷言要多寫註釋。同時維護一個包括全部斷言的debug版本和release版本。Debug版本只是用來差錯，大些慢些都不是問題。

3、像足球場入口檢票員那樣去防錯。使用內存日誌，對於根本不打算出城的「匪徒」，路障是沒有用的，咱們要和銀行檢查財務報告書中錯誤那樣自已有個「撥款清單」，主動和銀行的「撥款清單」對帳，挨家挨戶把「匪徒」抓出來。使用殼程序查錯。

4、常用斷點、逐條跟蹤、查看數據流的辦法運行代碼差錯。必要是除了C語言步進，還可使用匯編語言級別的步進運行每句代碼查錯。

5、糖果機容易誤導人的界面設計咱們堅定杜絕，遵照如下六條函數設計原則：

• 編寫功能單一的函數
• 返回值不該該隱藏錯誤碼
• 輸入參數要明肯定義，若是參數像realloc size 那麼多隱藏輸入範圍會隱藏錯誤而不是暴露錯誤，對於不合法的輸入要檢查。
• 編寫函數使其在給定有效輸入狀況下不會失敗
• 是程序調用點名了易懂，要避免布爾參數
• 先人們提醒險情，協商調用註釋和經常使用用法，突出可能的異常狀況

6、作設計寫程序要有風險意識，常常問設計和實現有多大的風險，有沒有更安全的方法，可否測試一下該設計，使用有嚴格定義的數據類型。常常反問：「這個表達式會上溢或下溢嗎？」，精確地實現設計而非近似地。

7、避免編程的假象。寫小說須要使讀者激動、吃驚、懸疑，而寫程序則要簡單直接。拿車鑰匙的賊仍是賊，釋放掉的存儲區再去引用就如同你使用過去的鑰匙進入曾經的公寓或開走曾經屬於你的汽車同樣。在設計函數過程當中，當須要向緩衝區傳遞數據時安全的方法是讓調用者分配一個局部（非靜態）的緩衝區。「一行清」也稱爲程序設計語言綜合症，不要寫通常水平的程序員編寫代碼。

做者說：「自動的抓住，不靠運氣，也不靠技巧，這就是編寫無錯代碼的方法」。

做者還說：「編寫無錯代碼的最好辦法是編譯時對其進行詳盡的測試」。

做者還還說過：「編寫無錯代碼最好的辦法是把防止錯誤放在第一位」。

是的以上就是編寫無錯代碼的方法。