譯者序
關於作者
關於技術審校
緻謝
第1章 簡介1
1.1 軟件熵2
1.2 整潔的代碼4
1.3 為什麼使用C 4
1.4 C 11—新時代的開始5
1.5 適閤本書的讀者5
1.6 本書使用的約定6
1.6.1 擴展閱讀6
1.6.2 說明、提示和警告6
1.6.3 示例代碼7
1.6.4 編碼風格7
1.7 相關網站和代碼庫7
1.8 UML圖8
第2章 構建安全體係9
2.1 測試的必要性9
2.2 測試入門11
2.3 單元測試13
2.4 關於QA15
2.5 良好的單元測試原則16
2.5.1 單元測試的代碼的質量16
2.5.2 單元測試的命名16
2.5.3 單元測試的獨立性17
2.5.4 一個測試一個斷言18
2.5.5 單元測試環境的獨立初始化19
2.5.6 不對getters和setters做單元測試19
2.5.7 不對第三方代碼做單元測試20
2.5.8 不對外部係統做單元測試20
2.5.9 如何處理數據庫的訪問20
2.5.10 不要混淆測試代碼和産品代碼21
2.5.11 測試必須快速執行23
2.5.12 測試替身24
第3章 原則27
3.1 什麼是原則27
3.2 保持簡單和直接原則（KISS）28
3.3 不需要原則（YAGNI）29
3.4 避免復製原則（DRY）29
3.5 信息隱藏原則30
3.6 高內聚原則33
3.7 鬆耦閤原則35
3.8 小心優化原則38
3.9 最少驚訝原則（PLA）39
3.10 童子軍原則39
第4章 C 代碼整潔的基本規範41
4.1 良好的命名42
4.1.1 名稱應該自解釋43
4.1.2 使用域中的名稱45
4.1.3 選擇適當抽象層次的名稱45
4.1.4 避免冗餘的名稱46
4.1.5 避免晦澀難懂的縮寫47
4.1.6 避免匈牙利命名和命名前綴47
4.1.7 避免相同的名稱用於不同的目的48
4.2 注釋49
4.2.1 讓寫代碼像講故事一樣49
4.2.2 不要為易懂的代碼寫注釋50
4.2.3 不要通過注釋禁用代碼50
4.2.4 不要寫塊注釋51
4.2.5 特殊情況的注釋是有用的53
4.3 函數56
4.3.1 隻做一件事情59
4.3.2 讓函數盡可能小59
4.3.3 函數命名61
4.3.4 使用容易理解的名稱61
4.3.5 函數的參數和返迴值62
4.4 C 工程中的C風格代碼72
4.4.1 使用C 的string和stream替代C風格的char*73
4.4.2 避免使用printf()、sprintf()和gets()等74
4.4.3 使用標準庫的容器而不是C風格的數組77
4.4.4 用C 類型轉換代替C風格的強製轉換80
4.4.5 避免使用宏81
第5章 現代C 的高級概念83
5.1 資源管理84
5.1.1 資源申請即初始化85
5.1.2 智能指針86
5.1.3 避免顯式的new和delete92
5.1.4 管理特有資源92
5.2 Move語義94
5.2.1 什麼是Move語義94
5.2.2 左值和右值的關係95
5.2.3 右值引用96
5.2.4 不要濫用Move97
5.2.5 零原則98
5.3 編譯器是你的搭檔102
5.3.1 自動類型推導102
5.3.2 編譯時計算105
5.3.3 模闆變量107
5.4 不允許未定義的行為108
5.5 Type-Rich編程110
5.6 瞭解你使用的庫116
5.6.1 熟練使用116
5.6.2 熟練使用Boost121
5.6.3 應該瞭解的一些庫121
5.7 恰當的異常和錯誤處理機製122
5.7.1 防患於未然123
5.7.2 異常即異常—字麵上的意思126
5.7.3 如果不能恢復則盡快退齣128
5.7.4 用戶自定義異常128
5.7.5 值類型拋齣，常量引用類型捕獲130
5.7.6 注意catch的正確順序130
第6章 麵嚮對象131
6.1 麵嚮對象思想132
6.2 抽象—解決復雜問題的關鍵因素133
6.3 類的設計原則134
6.3.1 讓類盡可能小134
6.3.2 單一職責原則（SRP）135
6.3.3 開閉原則（OCP）135
6.3.4 裏氏替換原則(LSP)136
6.3.5 接口隔離原則（ISP）146
6.3.6 無環依賴原則148
6.3.7 依賴倒置原則（DIP）151
6.3.8 不要和陌生人說話（迪米特法則）156
6.3.9 避免“貧血類”160
6.3.10 隻說不問160
6.3.11 避免類的靜態成員162
第7章 函數式編程164
7.1 什麼是函數式編程165
7.1.1 什麼是函數166
7.2.2 pure函數和impure函數167
7.2 現代C 中的函數式編程168
7.2.1 C 模闆函數編程168
7.2.2 仿函數170
7.2.3 綁定和函數包裝176
7.2.4 Lambda錶達式178
7.2.5 通用Lambda錶達式（C 14）180
7.3 高階函數181
7.4 整潔的函數式編程代碼186
第8章 測試驅動開發188
8.1 普通的舊單元測試的缺點189
8.2 測試驅動開發作為顛覆者190
8.2.1 TDD的流程190
8.2.2 TDD的一個小例子：Code Kata193
8.3 TDD的優勢210
8.4 什麼時候不應該使用TDD212
第9章 設計模式和習慣用法213
9.1 設計原則與設計模式214
9.2 常見的設計模式及應用場景214
9.2.1 依賴注入模式215
9.2.2 Adapter模式226
9.2.3 Strategy模式227
9.2.4 Command模式231
9.2.5 Command處理器模式235
9.2.6 Composite模式238
9.2.7 Observer模式241
9.2.8 Factory模式245
9.2.9 Facade模式248
9.2.10 Money Class模式249
9.2.11 特例模式252
9.3 什麼是習慣用法255
附錄A UML簡要指南266
參考文獻275
· · · · · · (收起)
關於作者
關於技術審校
緻謝
第1章 簡介1
1.1 軟件熵2
1.2 整潔的代碼4
1.3 為什麼使用C 4
1.4 C 11—新時代的開始5
1.5 適閤本書的讀者5
1.6 本書使用的約定6
1.6.1 擴展閱讀6
1.6.2 說明、提示和警告6
1.6.3 示例代碼7
1.6.4 編碼風格7
1.7 相關網站和代碼庫7
1.8 UML圖8
第2章 構建安全體係9
2.1 測試的必要性9
2.2 測試入門11
2.3 單元測試13
2.4 關於QA15
2.5 良好的單元測試原則16
2.5.1 單元測試的代碼的質量16
2.5.2 單元測試的命名16
2.5.3 單元測試的獨立性17
2.5.4 一個測試一個斷言18
2.5.5 單元測試環境的獨立初始化19
2.5.6 不對getters和setters做單元測試19
2.5.7 不對第三方代碼做單元測試20
2.5.8 不對外部係統做單元測試20
2.5.9 如何處理數據庫的訪問20
2.5.10 不要混淆測試代碼和産品代碼21
2.5.11 測試必須快速執行23
2.5.12 測試替身24
第3章 原則27
3.1 什麼是原則27
3.2 保持簡單和直接原則（KISS）28
3.3 不需要原則（YAGNI）29
3.4 避免復製原則（DRY）29
3.5 信息隱藏原則30
3.6 高內聚原則33
3.7 鬆耦閤原則35
3.8 小心優化原則38
3.9 最少驚訝原則（PLA）39
3.10 童子軍原則39
第4章 C 代碼整潔的基本規範41
4.1 良好的命名42
4.1.1 名稱應該自解釋43
4.1.2 使用域中的名稱45
4.1.3 選擇適當抽象層次的名稱45
4.1.4 避免冗餘的名稱46
4.1.5 避免晦澀難懂的縮寫47
4.1.6 避免匈牙利命名和命名前綴47
4.1.7 避免相同的名稱用於不同的目的48
4.2 注釋49
4.2.1 讓寫代碼像講故事一樣49
4.2.2 不要為易懂的代碼寫注釋50
4.2.3 不要通過注釋禁用代碼50
4.2.4 不要寫塊注釋51
4.2.5 特殊情況的注釋是有用的53
4.3 函數56
4.3.1 隻做一件事情59
4.3.2 讓函數盡可能小59
4.3.3 函數命名61
4.3.4 使用容易理解的名稱61
4.3.5 函數的參數和返迴值62
4.4 C 工程中的C風格代碼72
4.4.1 使用C 的string和stream替代C風格的char*73
4.4.2 避免使用printf()、sprintf()和gets()等74
4.4.3 使用標準庫的容器而不是C風格的數組77
4.4.4 用C 類型轉換代替C風格的強製轉換80
4.4.5 避免使用宏81
第5章 現代C 的高級概念83
5.1 資源管理84
5.1.1 資源申請即初始化85
5.1.2 智能指針86
5.1.3 避免顯式的new和delete92
5.1.4 管理特有資源92
5.2 Move語義94
5.2.1 什麼是Move語義94
5.2.2 左值和右值的關係95
5.2.3 右值引用96
5.2.4 不要濫用Move97
5.2.5 零原則98
5.3 編譯器是你的搭檔102
5.3.1 自動類型推導102
5.3.2 編譯時計算105
5.3.3 模闆變量107
5.4 不允許未定義的行為108
5.5 Type-Rich編程110
5.6 瞭解你使用的庫116
5.6.1 熟練使用116
5.6.2 熟練使用Boost121
5.6.3 應該瞭解的一些庫121
5.7 恰當的異常和錯誤處理機製122
5.7.1 防患於未然123
5.7.2 異常即異常—字麵上的意思126
5.7.3 如果不能恢復則盡快退齣128
5.7.4 用戶自定義異常128
5.7.5 值類型拋齣，常量引用類型捕獲130
5.7.6 注意catch的正確順序130
第6章 麵嚮對象131
6.1 麵嚮對象思想132
6.2 抽象—解決復雜問題的關鍵因素133
6.3 類的設計原則134
6.3.1 讓類盡可能小134
6.3.2 單一職責原則（SRP）135
6.3.3 開閉原則（OCP）135
6.3.4 裏氏替換原則(LSP)136
6.3.5 接口隔離原則（ISP）146
6.3.6 無環依賴原則148
6.3.7 依賴倒置原則（DIP）151
6.3.8 不要和陌生人說話（迪米特法則）156
6.3.9 避免“貧血類”160
6.3.10 隻說不問160
6.3.11 避免類的靜態成員162
第7章 函數式編程164
7.1 什麼是函數式編程165
7.1.1 什麼是函數166
7.2.2 pure函數和impure函數167
7.2 現代C 中的函數式編程168
7.2.1 C 模闆函數編程168
7.2.2 仿函數170
7.2.3 綁定和函數包裝176
7.2.4 Lambda錶達式178
7.2.5 通用Lambda錶達式（C 14）180
7.3 高階函數181
7.4 整潔的函數式編程代碼186
第8章 測試驅動開發188
8.1 普通的舊單元測試的缺點189
8.2 測試驅動開發作為顛覆者190
8.2.1 TDD的流程190
8.2.2 TDD的一個小例子：Code Kata193
8.3 TDD的優勢210
8.4 什麼時候不應該使用TDD212
第9章 設計模式和習慣用法213
9.1 設計原則與設計模式214
9.2 常見的設計模式及應用場景214
9.2.1 依賴注入模式215
9.2.2 Adapter模式226
9.2.3 Strategy模式227
9.2.4 Command模式231
9.2.5 Command處理器模式235
9.2.6 Composite模式238
9.2.7 Observer模式241
9.2.8 Factory模式245
9.2.9 Facade模式248
9.2.10 Money Class模式249
9.2.11 特例模式252
9.3 什麼是習慣用法255
附錄A UML簡要指南266
參考文獻275
· · · · · · (收起)
具體描述
使用現代C 編寫可維護、可擴展和持久的軟件。對於每一個對好的C 代碼感興趣的開發人員、軟件架構師或團隊領導來說，這本書都是必須的，因此也想節省開發成本。如果你想自學編寫整潔C 代碼，本書正是你所需要的。編寫它是為瞭幫助所有級彆的C 開發人員，並通過示例展示如何編寫可理解的、靈活的、可維護的和高效的C 代碼。即使是經驗豐富的C 開發人員，在本書中也會發現一些有用的信息和數據。
用戶評價
評分
##寫的還行，就是內容太多瞭，從語言語法糖到編程範式，再到設計模式，還有TDD，所以每個點都不深入，所以隻能說一般般
評分##必看的一本。
評分##寫的太簡略，很多部分和 C++ 沒有直接關係
評分##目前還有最後一章沒看完，強力推薦有兩三年C++ 經驗的朋友閱讀一下本書，你一定能從中獲得不少經驗。
評分除瞭現代C++概念之外其他的都還不錯。
評分##其實隻是代碼整潔之道的C++版本，如果你不認同代碼整潔之道的觀點，這本書也沒必要讀。如果你對寫整潔代碼有興趣，這是本好書。
評分##C++17的內容不多；一些觀點確實衝擊瞭我的認識
評分##必看的一本。
評分##溫習到瞭《代碼整潔之道》和《EFFECTIVE C++》中的很多東西，也見識瞭一些沒有學習的新內容。大概不能說多嶄新和新潮，但確實能提高不少C++熟練度。
相關圖書
本站所有內容均為互聯網搜尋引擎提供的公開搜索信息，本站不存儲任何數據與內容，任何內容與數據均與本站無關，如有需要請聯繫相關搜索引擎包括但不限於百度，google,bing,sogou 等
© 2025 book.teaonline.club All Rights Reserved. 圖書大百科 版權所有