阅读笔记：从 Clean Code 重新理解命名

《Clean Code》里关于命名的章节并不新鲜，但每次回看都会提醒我：代码可读性首先不是注释问题，而是名字有没有承担足够的信息量。

一个好名字不只是描述变量是什么，还应该暗示它为什么存在、如何被使用、边界在哪里。

命名传递意图

命名的第一层目标是避免读者猜测。比如 data、list、item 在局部很短的代码里可以接受，一旦跨越函数边界，就会迅速失去上下文。

更好的做法是把领域含义写进名字：

• posts 比 data 更清楚
• featuredPosts 比 list 更具体
• publishedAt 比 date 更能表达时间含义
• categoryCounts 比 counts 更容易复用

const featuredPosts = posts.filter((post) => post.featured);
const categoryCounts = categories.map((category) => ({
  category,
  count: posts.filter((post) => post.category === category).length
}));

这段代码没有复杂技巧，但名字把数据的来源、筛选条件和使用目标都交代清楚了。

避免误导

坏名字最麻烦的地方不是短，而是误导。postList 如果实际是 Map，isReady 如果还会触发副作用，都会让读者建立错误预期。

可以用几个问题检查命名：

• 名字是否和真实类型一致
• 布尔值是否能被自然读成判断句
• 函数名是否暴露了副作用
• 缩写是否是团队共识，而不是个人习惯

function hasPublishedPosts(posts: Post[]) {
  return posts.some((post) => post.date <= today());
}

这里用 has 开头，读者会预期返回布尔值。这样的微小约定能让代码在扫描时更顺滑。

放到日常实践里

命名不是一次性追求完美。更实际的做法是在写完功能后回头读一遍：如果需要在脑中翻译某个变量，就改名；如果函数名无法解释返回值，也改名。

小结

Clean Code 的命名原则最终指向同一件事：尊重下一位读代码的人。很多时候，那个人就是两周后的自己。