編輯推薦
被china-pub會員評為“2007年我最喜愛的十大技術圖書”之一
被《程式設計師》等機構評選為2006年最受讀者喜愛的十大IT圖書之一
是著名IT暢銷書作者Steve McConnell十一年前的經典著作的全新演繹，該作者是兩屆Software Development Magzine Jolt Award震撼大獎得主
內容簡介
這也是一本完整的軟體構建手冊，涵蓋了軟體構建過程中的所有細節。它從軟體質量和編程思想等方面論述了軟體構建的各個問題，並詳細論述了緊跟潮流的新技術、高屋建瓴的觀點、通用的概念，還含有豐富而典型的程式示例。本書中所論述的技術不僅填補 了初級與高級編程技術之間的空白，而且也為程式設計師們提供了一個有關編程技巧的信息來源。本書對經驗豐富的程式設計師、技術帶頭人、自學的程式設計師及幾乎不懂太多編程技巧的學生們都是大有裨益的。可以說，無論你是什麼背景，閱讀本書都會讓你在更短的時間內、更容易地寫出更好的程式。
代碼大全是我早在好幾年前便已經閱讀過的好書。這幾年來我不知買過多少書籍，也清理過許多因為書房再也放不下的書籍，但是代碼大全這本書始終占據著我書架上重要的位置而不曾移開過，因為好書是經得起時光考驗的。
—— borland公司大中華首席技術官（cto） 李維
在眾多的編程類書籍中，如果只讓我挑一本書來閱讀，那我一定選擇《代碼大全》，因為它是最不可或缺的。
—— 《c++ primer中文版（第三版）》譯者 潘愛民
作譯者
Steve McConnell是Construx公司首席軟體工程師，在公司里監督軟體工程實施。他是軟體工程知識體(SWEBOK) 項目構建知識領域的領導。Steve曾為微軟公司、波音公司和西雅圖地區的公司工作過。
Steve McConnell是以下著作的作者：1996年的《快速軟體開發（Rapid Development）》、1998年的《軟體項目長存之道（Software Project Survival Guide）》和2004年的《專業軟體開發（Professional Software Development）》。他的書由於傑出，曾兩度獲得當年的《軟體開發（Software Development）》雜誌的優秀震撼大獎
目錄
第1章 歡迎進入軟體構建的世界 3
1 1 什麼是軟體構建？ 3
1 2 軟體構建為何如此重要？ 6
1 3 如何閱讀本書 8
關鍵點 8
第2章 用隱喻來更充分地理解軟體開發 9
2 1 隱喻的重要性 9
2 2 如何使用軟體隱喻 11
2 3 常見的軟體隱喻 13
軟體中的書法：寫作代碼 13
軟體的耕作法：培植系統 14
軟體的牡蠣養殖觀點：系統生長 15
軟體構建：建造軟體 16
套用軟體技術：智慧工具箱 20
組合各個隱喻 20
更多資源 20
關鍵點 21
第3章 三思而後行：前期準備 23
3 1 前期準備的重要性 24
前期準備適用於現代軟體項目嗎？ 25
準備不周全的誘因 25
關於開始構建之前要做前期準備的絕對有力且簡明的論據 27
3 2 辨明你所從事的軟體的類型 31
疊代開發法對前期準備的影響 33
在序列式開發法和疊代式開發法之間做出選擇 35
3 3 問題定義的先決條件 36
3 4 需求的先決條件 38
為什麼要有正式的需求？ 38
穩定需求的神話 39
在構建期間處理需求變更 40
3 5 架構的先決條件 43
架構的典型組成部分 45
3 6 花費在前期準備上的時間長度 55
更多資源 56
關鍵點 59
第4章 關鍵的“構建”決策 61
4 1 選擇程式語言 61
語言描述 63
4 2 編程約定 66
4 3 你在技術浪潮中的位置 66
“深入一種語言去編程”的例子 68
4 4 選擇主要的構建實踐方法 69
關鍵點 70
第5章 軟體構建中的設計 73
5 1 設計中的挑戰 74
設計是一個險惡的問題 74
設計是個了無章法的過程（即使它能得出清爽的成果） 75
設計就是確定取捨和調整順序的過程 76
設計受到諸多限制 76
設計是不確定的 76
設計是一個啟發式過程 76
設計是自然而然形成的 76
5 2 關鍵的設計概念 77
軟體的首要技術任務：管理複雜度 77
理想的設計特徵 80
設計的層次 82
5 3 設計構造塊：啟發式方法 87
尋找現實世界中的對象 87
形成一致的抽象 89
封裝實現細節 90
當繼承能簡化設計時就繼承 91
隱藏秘密（信息隱藏） 92
找出容易改變的區域 97
保持鬆散耦合 100
查閱常用的設計模式 103
其他的啟發式方法 105
關於設計啟發的總結***** 108
使用啟發式方法的原則 109
5 4 設計實踐 110
疊代 110
分而治之 111
自上而下和自下而上的設計方法 111
建立試驗性原型 114
合作設計 115
要做多少設計才夠？ 115
記錄你的設計成果 117
5 5 對流行的設計方法的評論 118
更多資源 119
軟體設計，一般性問題 119
軟體設計理論 120
設計模式 120
廣義的設計 121
標準 122
關鍵點 122
第6章 可以工作的類 125
6 1 類的基礎：抽象數據類型 126
需要用到adt的例子 126
使用adt的益處 127
更多的adt示例 129
在非面向對象環境中用adt處理多份數據實例 131
adt和類 133
6 2 良好的類接口 133
好的抽象 133
良好的封裝 139
6 3 有關設計和實現的問題 143
包含（“有一個……”的關係） 143
繼承（“是一個……”關係） 144
成員函式和數據成員 150
構造函式 151
6 4 創建類的原因 152
應該避免的類 155
總結：創建類的理由 155
與具體程式語言相關的問題 156
6 6 超越類：包 156
更多資源 159
關鍵點 160
第7章 高質量的子程式 161
7 1 創建子程式的正當理由 164
似乎過於簡單而沒必要寫成子程式的操作 166
總結：創建子程式的理由 167
7 2 在子程式層上設計 168
7 3 好的子程式名字 171
7 4 子程式可以寫多長 173
7 5 如何使用子程式參數 174
7 6 使用函式時要特別考慮的問題 181
什麼時候使用函式，什麼時候使用過程 181
設定函式的返回值 182
7 7 宏子程式和內聯子程式 182
宏子程式在使用上的限制 184
內聯子程式 184
關鍵點 186
第8章 防範式編程 187
8 1 保護程式免遭無效輸入數據的破壞 188
8 2 斷言 189
建立自己的斷言機制 191
使用斷言的指導建議 191
8 3 錯誤處理技術 194
健壯性與正確性 197
高層次設計對錯誤處理方式的影響 197
8 4 異常 198
8 5 隔離程式以免遭由錯誤造成的損害 203
隔離區與斷言的關係 205
8 6 輔助調試代碼 205
不要自動地把產品版本的限制強加於開發版本之上 205
儘早引入輔助調試的手段 206
採用冒進式編程 206
計畫移除調試輔助代碼 206
8 7 確定在產品代碼中該保留多少防範式代碼 209
8 8 防範式編程時保持防範 210
其他資源 212
關鍵點 213
第9章 偽代碼編程過程 215
9 1 創建類和子程式的步驟概述 216
創建一個類的步驟 216
創建子程式的步驟 217
9 2 偽代碼 218
9 3 通過偽代碼編程過程創建子程式 220
設計子程式 225
編寫子程式 225
檢查代碼 230
收尾工作 232
根據需要重複上述步驟 232
9 4 偽代碼編程過程之外的其他方案 232
關鍵點 234
第10章 使用變數的一般事項 237
10 1 數據認知 238
數據認知測試 238
有關數據類型的其他資源 239
10 2 輕鬆掌握變數定義 239
隱式聲明 239
10 3 變數初始化原則 240
10 4 作用域 244
使變數引用局部化 245
儘可能縮短變數的“存活”時間 246
減小作用域的一般原則 249
有關縮小變數作用域的說明 250
10 5 持續性 251
10 6 綁定時間 252
10 7 數據類型和控制結構之間的關係 254
10 8 為變數指定單一用途 255
關鍵點 258
第11章 變數名的力量 259
11 1 選擇好變數名的注意事項 259
最重要的命名注意事項 260
以問題為導向 261
最適當的名字長度 262
變數名字的效果範圍 262
變數名字中的計算值限定詞 263
變數名字中的常用反義詞 264
11 2 為特定類型的數據命名 264
為循環索引命名 265
為狀態變數命名 266
為臨時變數命名 267
為布爾變數命名 268
為枚舉類型命名 269
為常量命名 270
11 3 命名規則的力量 270
為什麼要有規則？ 270
何時採用命名規則 271
正式程度 271
11 4 非正式命名規則 272
語言無關規則的指導原則 272
語言相關規則的指導原則 275
混合語言編程的注意事項 276
命名規則示例 276
11 5 標準前綴 279
用戶自定義類型縮寫 279
語義前綴 280
標準前綴的優點 281
11 6 創建具備可讀性的短名稱 282
一般的縮寫指導原則 282
語音縮寫 282
有關縮寫的評論 282
11 7 應該避免的名稱 285
關鍵點 289
第12章 基本數據類型 291
12 1 使用數的普遍規則 292
12 2 整數 293
12 3 浮點數 295
12 4 字元和字元串 297
c中的字元串 299
12 5 布爾變數 301
12 6 枚舉類型 303
如果你的語言裡沒有枚舉類型 307
12 7 命名常量 307
12 8 數組 310
12 9 創建你自己的類型（類型別名） 311
為什麼創建自己的類型的示例是用pascal和ada寫的？ 314
創建自定義數據類型的指導原則 315
關鍵點 318
第13章 不常見的數據類型 319
13 1 結構 319
13 2 指針 323
用來理解指針的例子 323
使用指針的一般技巧 325
c++指針 332
c指針 334
13 3 全局數據 335
與全局數據有關的常見問題 335
使用全局數據的理由 338
只有萬不得已時才使用全局數據 339
用訪問子程式來取代全局數據 339
如何降低使用全局數據的風險 342
其他資源 343
關鍵點 344
第14章 組織直線型代碼 347
14 1 必須有明確順序的語句 347
14 2 順序無關的語句 351
使代碼易於自上而下的閱讀 351
把相關的語句組織在一起 352
關鍵點 353
第15章 使用條件語句 355
15 1 if語句 355
簡單if-then語句 355
if-then-else語句串 358
15 2 case語句 361
為case選擇最有效的排序 361
使用case語句的提示 361
關鍵點 366
第16章 控制循環 367
16 1 選擇循環的種類 367
什麼時候使用while循環 368
什麼時候用帶退出的循環 369
何時使用for循環 372
何時使用foreach循環 372
16 2 循環控制 373
進入循環 373
處理好循環體 375
退出循環 377
檢查端點 381
使用循環變數 382
循環應該有多長？ 385
16 3 輕鬆創建循環——由內而外 385
16 4 循環和數組的關係 387
關鍵點 389
第17章 不常見的控制結構 391
17 1 子程式中的多個返回 392
17 2 遞歸 393
遞歸的例子 394
使用遞歸的技巧 396
17 3 goto 398
反對goto的論點 398
支持goto的觀點 399
關於goto的虛假辯論 400
錯誤處理和goto 401
goto和在else子句中的共享代碼 406
goto使用原則總結 407
17 4 對不常見控制結構的看法 408
其他資源 408
關鍵點 410
第18章 表驅動方法 411
18 1 表驅動方法使用總則 411
使用表驅動方法的兩個問題 412
18 2 直接訪問表 413
示例：一個月中的天數（days-in-month） 413
示例：保險費率 415
例子：靈活的訊息格式（flexible-message-format） 416
構造查詢鍵值 423
18 3 索引表訪問（indexed access tables） 425
18 4 階梯訪問表 426
18 5 表查詢的其他示例 429
關鍵點 430
第19章 一般控制問題 431
19 1 布爾表達式 432
用true和false做布爾判斷 432
簡化複雜的表達式 434
編寫肯定形式的布爾表達式 436
用括弧使布爾表達式更清晰 438
理解布爾表達式是如何求值的 439
writing numeric expressions in number-line order 441
按照數軸的順序編寫數值表達式 441
guidelines for comparisons to 0 442
與0比較的指導原則 442
common problems with boolean expressions 443
布爾表達式的常見問題 443
19 2 compound statements (blocks) 444
19 2 複合語句（塊） 444
19 3 null statements 445
19 3 空語句 445
19 4 taming dangerously deep nesting 446
19 4 馴服危險的深層嵌套 446
summary of techniques for reducing deep nesting 454
對減少嵌套層次的技術的總結 454
19 5 a programming foundation: structured programming 455
19 5 編程基礎：結構化編程 455
the three components of structured programming 455
結構化編程的三個組成部分 455
19 6 control structures and complexity 457
19 6 控制結構與複雜度 457
how important is complexity? 458
複雜度的重要性 458
general guidelines for reducing complexity 458
降低複雜度的一般原則 458
other kinds of complexity 460
其它類型的複雜度 460
checklist: control-structure issues 460
檢查表：控制結構相關事宜 460
key points 461
關鍵點 461
譯者序
這本書講什麼
《經典代碼大全》這本書的原名叫《Classic Code Complete》，那么Classic Code Complete 在這裡是何含義呢？首先，它不代表現代集成開發環境（IDE）中的代碼自動補全功能，本書也不打算向您講解Eclipse 或Visual Studio 2005 中的代碼自動補全功能是如何實現的?。其次，Classic Code Complete 也不是真正的軟體原始碼“大全”的意思??，這本書既沒有列出連線各種資料庫的代碼、也沒有列出網頁中常用的各種JavaScript 代碼。書中的代碼示例恐怕也不能直接copy&paste 代碼到您自己的項目中。
那么Classic Code Complete 到底是什麼意思？中譯本為什麼又要取名為“代碼大全”呢？雖然從網上討論的情況看，各位網友對書名含義的理解有出入，但是譯者有充分的理由相信，Classic Code Complete 是“編碼完成”的意思，是一個軟體項目開發過程中的重要里程碑（milestone）。
軟體項目進行到這裡，表明已經完成了所有的編碼工作，即將開始系統測試。
這本書講的正是為了到達“編碼完成”這一重要里程碑所必需的軟體構建技術，確切地說，就是如何編寫高質量的代碼。作者認為，應該首先為人編寫代碼，其次才是為機器（第34 3 節）；代碼主要是供人閱讀的。遍布全書的提高代碼質量的實實在在的技術和訣竅，是本書最有價值的部分。事實上，我們認為第6、7、10 至19 章這300 多頁的內容是本書的精華內容，在其他書里恐怕很難找到如此詳盡的對變數、語句、子程式等編程基本要素的討論。
十多年前，本書第1 版以《代碼大全》為名翻譯出版，在過去的10 餘年中，這本書影響了整整一代程式設計師，“代碼大全”四個字已成為一個響噹噹的名字。鑒於此，本書第2版決定保留這個無傷大雅的“錯誤”，沿用“代碼大全”作為書名，也藉此向原書第1 版各位譯者、修訂者們的辛勤勞動表示我們的敬意。無論如何，對Classic Code Complete 的理解不會影響對整本書的理解。
本書除了講如何構建高質量的軟體，還講如何成為一名優秀的程式設計師（第33 章“個人性格”、第4 3 節“你在技術浪潮中的位置”、第34 4 節“深入一門語言去編程”）。
前言
普通的軟體工程實踐與最優秀的軟體實踐差距巨大——多半比其他工程學科中的這種差距都要大。因此，傳播優秀實踐經驗的工具是十分重要的。
—— Fred Brooks
我寫這本書的首要目的，就是希望縮小本行業中一般商業實踐與大師級人物及專家們之間的知識差距。許多強大的編程技術在被編程領域的大眾接觸之前，都已在學術論文和期刊里塵封了多年。
雖然近年來前衛的軟體開發實踐迅速發展，但普通的實踐手段並沒有太大變化。
很多程式的開發仍然是漏洞百出、遲於交付並且超出預算，還有很多根本就無法滿足用戶的需求。軟體業界以及學術界的研究人員已經發現了不少行之有效的實踐經驗，足以解決自20 世紀70 年代以來編程領域中日益蔓延的大多數問題。可是這些實踐經驗很少在高度專業化的技術期刊之外對外發表，所以時至今日大多數編程的機構和組織還沒能用上這些技術。有研究表明，一項研發成果從其誕生之日起，到進入商業實踐階段，通常要經歷5 到15 年甚至更長的時間（Raghavan and Chand 1989；Rogers 1995；Parnas 1999）。這本手冊就是想縮短這一漫長的過程，讓那些關鍵性的研發成果現在就能為更多編程人員所用。
Who Should Read This Book
誰應當閱讀本書
本書中所匯集的研究成果和編程經驗，將幫助你創建更高質量的軟體，使你能更快速地進行開發，遇到的問題更少。本書將幫你弄明白過去為什麼會遇到那些問題，並告訴你如何在將來避免它們。這裡所描述的編程實踐將幫助你掌控更大型的項目，還能在項目的需求發生變動時幫助你成功地維護並修改已經開發出來的軟體。
Experienced Programmers
經驗豐富的程式設計師
對於經驗豐富的程式設計師而言，本書正是他們想要的一本翔實、易用的軟體開發指南。
本書關注的是“構建（construction）”，即整個軟體生命周期中最為人熟知的部分；本書把強大的軟體開發技術寫得讓自學的程式設計師和參加過正規訓練的程式設計師都能讀懂。
