【编写可读代码的艺术】写给程序员的情书

省流版：有人说，看一个程序员写的代码，就像在读他的日记——是不是清晰、有逻辑、有责任感，一目了然。说得更直接一点：你写的不是代码，是你对同事的尊重，对未来自己的体贴，以及对这份职业的敬畏。

很多公司把“代码审美”挂在嘴边，但一问标准，全是玄学。而真正的高手，都在用一句朴素的标准判断代码的好坏：

📌 “能不能一眼看懂。”

可读性，不是加注释就够了

让我们先打破一个常见误区：可读性不是注释写得多，而是_代码本身就能说话_。

一段代码，如果需要一长串注释才能说明白它干了什么，基本可以断定：命名烂、结构乱、变量多、逻辑绕。

注释的最高境界，不是“我把注释写明白了”，而是我把代码写得根本不需要注释。这不是炫技，而是责任。

写代码，先想名字

我们大多数人从 Hello World 一路写到中间件，绕不过的第一个功课就是起名字。

变量名、函数名、类名，都是我们留给团队的“小纸条”。清楚明白的名字就是一种节约：省下同事几分钟阅读时间，也省下未来你 debug 时的几口老血。

比如你写了一个方法叫 GetPage()，好，那它是从缓存里拿？数据库里查？还是调接口下载？全靠猜。

不如改成：

• FetchPageFromCache()
• DownloadPageFromInternet()
• QueryPageFromDB()

清晰胜于聪明，明确强于装可爱。别再用 tmp、data、retval 这些词当心理安慰了。

不要让读者追踪你的变量

程序里最容易失控的生物，不是 bug，是变量。

变量一多，脑袋发懵；变量作用域太大，忘了在哪用的；变量值变来变去，就像在看谍战片。

最佳做法很简单：让变量的“活动范围”越小越好，值越不变越好。能 const 的就别留活口。能一步到位的，就别引入“中间变量”。

你写一行代码，相当于埋一个地雷。变量一多，团队就在雷区里办公。

让结构说话，而不是读者来猜

我们曾经看到一段三层嵌套的 if-else，还夹杂着两个三目运算符，配合 do-while 和 break，看得人脑中打转，键盘都想摔了。

建议：

• 控制流尽量浅显，能早返回就早返回；
• 复杂表达式尽量拆解，用“解释变量”命名；
• 类似代码块写得像一点，不要东一榔头西一棒。

如果读代码像在爬楼梯，那你就多加几个扶手。

好的代码，是有审美的

我们不是在写诗，但好代码的确有“美”。

它排版一致、逻辑清晰、布局分明，读起来节奏自然、眼睛不累、心情舒畅。

它会自觉地用空行把不同功能区隔开，把相关逻辑写在一起，甚至函数的排列顺序都有讲究。

审美不是艺术，是习惯，是对质量的最低要求。

写代码是为了被人理解，不是炫技

这本讲代码可读性的书中有一句话让我印象深刻：

“代码的写法应当使别人理解它所需的时间最小化。”

是的，最小化认知负担，不是最小化行数。短不等于好，一行写完不等于优雅，别人改不了才是真的糟。

写得短是能力，写得清晰才是品格。

写在最后：代码是团队文化的镜子

在一家有责任感的技术团队里，代码从不是一个人的“作品”，而是整个组织的语言和风格。

能不能一眼看懂，能不能快速 debug，能不能轻松测试，其实反映的不是某个工程师的水平，而是整个团队对“专业主义”的共识。

所以，下次你想快速把功能写完时，请再多想三秒钟：

“我这行代码，是未来某人掉进坑里的开口，还是他顺利推进的阶梯？”

写代码，不只是写功能，而是在写你对身边人的尊重。