書中對於**規範有非常詳細的講解和舉例，是非常有價值的參考資料。編譯技術似乎不僅僅是一種溝通和交流的機制。如果從編譯技術的發展和演化上去推究，編譯技術倒更像是貫穿不同的軟體文化、聯結不同的技術發展階段的一座橋梁。許多計算機軟體發展史上值得人們注意的關鍵事件，許多煊赫一時、引得全世界程式設計師們趨之若鶩的技術體系，都與編譯技術本身有著直接或者間接的關聯。
風格篇：
程式中「注釋」的最重要的功效在於傳承。傳承一般有兩種情況。第一，寫**的人寫完這段**之後會去寫下一段**、下下一段**，直寫到東西莫辨、朝午不明，也許過了一年半載以後，客戶提出新的改動需求時，他才會回過頭來看原來的**。為了在未來的某個時候更快地接上當時編碼的思路，更好地理解已塵封數月的程式，當然要未雨綢繆，事先就寫好注釋，否則不被老闆痛罵才怪。第二，沒有人願意永遠維護自己寫過的**，也沒有老闆可以保證手下的程式設計高手不會另擇高枝，所以心地善良的程式設計師們總會寫好注釋(當然還有設計文件)以方便他人，自己也可以順便找些「前人栽樹，後人乘涼」的幸福感覺來。因此，就「傳承」而言，注釋至少應該具備以下這些特點:
第一，注釋應當淺顯、明白。給程式加上些詰屈整牙、形同天書的注釋還不如不加的好。舉個例子，我見過乙個程式設計師把注釋當作了他的私人日記本，在**的注釋中用只有他自己才懂得的特殊標記，把他在開發過程中的感想、計畫、設計思路都記下來。
注釋不是越多越好。
不要亦步亦趨。
多站在後來者的角度想一想。
風格不要妨礙溝通。
混合多種風格等於沒有風格。
沒有個性特點的**未必就是好**。
任何語法規則都有被濫用的可能。風格的優劣取決於選擇的正確與否。
選擇的前提是:由此產生的**更加簡潔、清晰、高效、易維護。
只有在必要的情況下，才使用特殊的編譯選項。
一定要注意你自己對編譯選項的選擇是否會給專案組的其他成員，或今後的**維護人員帶來麻煩。
編碼篇：
今天的物件導向理論至少還面臨著以下置疑:
1.物件導向方法的培訓週期明顯長於結構化方法，教科書卻還在大肆宣揚物件導向的概念更符合人類的思維習慣，更容易掌握。
2.「物件導向的軟體工程」顯然與傳統的軟體工程理論有相當大的差異，即使是 rational 公司的那幾個開山鼻祖也還在不斷地對他們的理論修修補補。
3.uml只是物件導向設計的開始。目前的uml還有些難以理解，對複雜應用的表達能力也還比較有限。
4．適應於物件導向機制的測試理論和自動測試工具都亟待發展，距離成熟易用的階段好像還比較遙遠。
5．多型性、多重繼承、虛基類、私有成員、內嵌類……這些都是物件導向技術對測試人員的信心和能力的挑戰。要知道，一段只有10行的新**很可能會讓 100 000行已經測試過的**暴露出新的錯誤。
6.事件-訊息處理機制至今沒有一種通行的標準。
7.「異常處理」技術很容易被不那麼有經驗的程式設計師們變成一種新的「義大利麵條」製造器，因為誰也沒辦法很快弄清楚乙個擁有15種異常物件和7層異常巢狀的**，其實際執行順序到底是怎樣的。
8．基於物件導向理論的通訊和分布式應用模型還處在變動之中。corba和 dcom的競爭還沒有結束，soap和web services也許只適用於某些應用，傳統的named pipe，sockets 和 rpc還在大行其道。
9.…….
我們知道，**中隨意出現的goto會使程式流程混亂不堪，但多重迴圈中的goto 顯然可以更清楚、更快速地跳到所有迴圈之外。典型的多重迴圈的例子經常出現在3d建模、影象處理、統計學等喜歡使用多維陣列的場合。
讀《凌波微步 軟體開發警戒案例集》有感
首先書的前言說了真正的程式設計高手是在千錘百鍊之後誕生的，尤其珍貴的文中的秘籍，將會是無名小卒脫胎換骨的利刃。其次書上給出的注釋還有以下特點 1.注釋應當淺顯，明白。2.注釋不是程式設計師的指南。3.注釋不是標準庫函式參考手冊。4.注釋的主要任務是答疑解惑。5.好的注釋是對設計思想的精確表述和清晰展...
《凌波微步 軟體開發警戒案例集》學習日誌
首先說 構建之法 這本書中提到的 規範，程式設計師寫的 是給人看的，還是給機器看的？答案是，人也看，機器也看，但最終是人在看。我們的 要讓旁觀者看的清清楚楚。規範可以分成兩個部分 1 風格規範。主要是文字上的規範，看似表面文章，實際上非常重要。2 設計規範。牽涉到程式設計 模組之間的關係 設計模式等...
凌波微步軟體開發警戒案例集讀後感
凌波微步軟體開發警戒案例集讀後感 說實話，當我看到這本書的時候，眼前一亮，它不像其他的書籍那麼死板，作者把內容寫得很有趣，最重要的是，他所分享的事情都是真觸動人心的，作者行業知識豐富，案例寫得生動有趣就不說了，每章開頭引經據典也反映出作者知識面廣。要有廣度有深度，這對同行的自己是有啟示的，有人說本書...