讀《代碼大全 2》第 4 章有感
重讀《代碼大全 2》第 4 章 “關鍵的編碼決策”，仿佛在開發迷霧中找到了一盞 “落地燈”。不同于晦澀的理論專著，這一章以 “如何做出更優編碼選擇” 為核心，把變量命名、函數設計、控制結構這些看似基礎的環節，拆解成了可落地的 “編碼準則”，讓我對 “好代碼” 的認知從 “模糊感覺” 變成了 “清晰標準”。
最讓我共鳴的是 “變量命名：清晰優先于簡潔” 這部分。以前寫代碼總追求 “短變量”，比如用u代表 “用戶”、t代表 “時間”，覺得這樣敲鍵盤更快。直到一次維護半年前的項目，看到if (u.t > maxT)這樣的代碼，愣了三分鐘才反應過來是 “判斷用戶登錄時間是否超過最大限制”。而書中強調的 “使用描述性命名，讓變量‘自解釋’”，恰好戳中了我的痛點 —— 后來我把u改成user、t改成loginTime，不僅自己再看代碼時不用 “回憶上下文”，團隊協作時同事也不用反復來問 “這個變量到底是什么意思”。原來好的命名不是 “浪費字符”，而是在減少后續的溝通成本和理解成本。
同樣顛覆我認知的還有 “函數設計：每個函數只做一件事”。之前我總喜歡寫 “大函數”，比如把 “獲取用戶信息、驗證用戶權限、更新用戶日志” 全塞進一個handleUser()函數里，函數行數常常超過 200 行。每次要修改 “權限驗證邏輯”，都得小心翼翼地在大函數里找對應的代碼塊，生怕改壞其他功能。而書中舉的例子讓我恍然大悟：把handleUser()拆成getUserInfo()、checkUserPermission()、updateUserLog()三個小函數，每個函數只負責一個明確的任務，不僅代碼結構一目了然，修改時也能 “精準定位”—— 比如調整權限規則，只需要改checkUserPermission()，完全不用碰其他兩個函數。這種 “拆分思維”，讓我后來寫的代碼 bug 率明顯下降，維護起來也輕松了很多。
章節里關于 “控制結構：避免嵌套過深” 的建議，也讓我受益良多。以前寫多條件判斷時，總習慣用 “if 嵌套 if”，比如：
if (user != null) {
if (user.isActive()) {
if (user.hasPermission()) {
// 執行操作
}
}
}

三層嵌套下來，代碼像 “階梯” 一樣越來越靠右，讀起來很費勁。書中推薦的 “提前返回” 寫法，讓我重構了這段代碼：
if (user == null) return;
if (!user.isActive()) return;
if (!user.hasPermission()) return;
// 執行操作

去掉嵌套后，代碼變得 “平鋪直敘”，邏輯一眼就能看明白。原來控制結構的優化，不只是 “代碼美觀” 的問題，更是 “邏輯清晰度” 的關鍵 —— 嵌套越少，大腦理解起來的 “認知負荷” 就越低，越不容易出錯。
讀完這一章，我最大的感受是：編碼不是 “把功能實現就行” 的機械勞動，而是需要 “精打細算” 的工程實踐。變量命名、函數拆分、控制結構這些看似 “細節” 的選擇，恰恰決定了代碼的可讀性、可維護性和可靠性。《代碼大全 2》沒有用高深的理論 “說教”，而是用一個個貼近實際開發的案例，告訴我們 “好代碼是怎么設計出來的”。往后寫代碼時，我會把這章的準則當成 “檢查清單”：變量名是否能 “自解釋”？函數是否只做了一件事？控制結構有沒有嵌套過深？唯有把這些 “基礎環節” 做扎實，才能寫出真正經得起時間考驗的代碼。