读后感

读《代码大全 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》没有用高深的理论 “说教”，而是用一个个贴近实际开发的案例，告诉我们 “好代码是怎么设计出来的”。往后写代码时，我会把这章的准则当成 “检查清单”：变量名是否能 “自解释”？函数是否只做了一件事？控制结构有没有嵌套过深？唯有把这些 “基础环节” 做扎实，才能写出真正经得起时间考验的代码。