故意不写注释（“优秀的代码不需要注释”）

作者：陈川阅读数：64083人阅读分类：前端综合

优秀的代码不需要注释，这是许多自信过头的开发者常挂在嘴边的话。他们坚信自己的代码逻辑清晰到足以让任何人在十年后依然能一眼看懂。然而，现实往往是：三个月后的自己对着屏幕骂骂咧咧，而同事则默默在代码审查里留下“WTF”的评论。

如何用“自解释代码”制造混乱

“自解释代码”是拒绝注释的最佳借口。比如，一个函数名叫 processData，看起来足够清晰，但没人知道它到底处理了什么数据、怎么处理、以及为什么要处理。更妙的是，在函数内部用一堆缩写变量名，比如：

function processData(d) {
  const fD = d.filter(x => x.s);
  const mD = fD.map(x => ({ ...x, v: x.v * 2 }));
  return mD.sort((a, b) => b.v - a.v);
}

这段代码的“自解释性”体现在：

d 可能是数据，但没人知道它的结构。
x.s 是什么？是 status？是 selected？还是 secret？
v 又代表什么？value？velocity？vampireCount？
排序的逻辑是“降序”，但为什么是降序？业务需求？还是开发者心情不好？

如果加上注释，这段代码可能会失去它的“艺术性”——毕竟，注释会破坏这种“猜谜游戏”的乐趣。

用魔法数字和硬编码提升代码的“不可维护性”

注释的另一个天敌是魔法数字。比如：

function calculateDiscount(price) {
  return price * 0.7;
}

这里的 0.7 是打 7 折的意思，但为什么不写注释呢？因为：

未来维护者可能会以为这是某种神秘系数，比如“70% 的用户喜欢这个折扣”。
如果业务改成 8 折，未来的开发者可能会直接改成 0.8，而不知道这个数字原本是“30% off”的意思。

更高级的做法是结合多个魔法数字，让逻辑彻底变成黑盒：

function calculatePrice(quantity) {
  return quantity * 42 + 3.14 * Math.log(quantity);
}

没人知道 42 和 3.14 是什么，但注释会破坏这种“数学之美”。

用条件分支的嵌套制造“逻辑迷宫”

避免注释的另一个技巧是让代码逻辑复杂到没人敢动。比如：

function getUserAccessLevel(user) {
  if (user.role === 'admin') {
    if (user.department === 'IT') {
      return 'full';
    } else if (user.department === 'HR') {
      return user.isTemporary ? 'restricted' : 'full';
    }
  } else if (user.role === 'editor') {
    return user.hasApproval ? 'partial' : 'none';
  } else {
    return 'none';
  }
}

这段代码的“优雅”之处在于：

没人知道 'full'、'restricted'、'partial'、'none' 具体代表什么权限。
isTemporary 和 hasApproval 的影响范围隐藏在嵌套逻辑里。
如果未来要加一个新角色，维护者必须小心翼翼地避免破坏现有的神秘逻辑。

如果加上注释，这段代码可能会变得“太容易理解”，从而失去它的“防御性编程”价值。

用“未来可能用到的参数”提升代码的灵活性

为了让代码更“未来友好”，可以在函数里加一些看似无用但“说不定哪天会用上”的参数。比如：

function formatDate(date, options = {}) {
  // options 目前没有任何作用，但未来可能会支持时区、格式等
  return date.toISOString();
}

这样做的优势是：

未来的开发者在调用这个函数时，会疑惑 options 到底能干嘛。
如果他们尝试传参，比如 formatDate(new Date(), { timezone: 'UTC' })，会发现毫无效果，从而陷入深深的自我怀疑。
如果未来真的需要扩展，他们可能会直接重写这个函数，而不是去研究原来的“假扩展性”。

用“自我优化”的代码让逻辑不可追踪

“自我优化”是指那些为了“性能”或“简洁”而写的、但实际让逻辑更难理解的代码。比如：

const result = data.reduce((acc, curr) => 
  (acc[curr.id] = { ...curr, processed: true }, acc), {});

这段代码的“精妙”之处在于：

它用逗号操作符 (,) 来“优雅”地省略 return。
它直接在 reduce 里修改 acc，同时返回它，让人不确定是否有副作用。
它用解构赋值 (...curr) 来“优化”对象合并，但没人知道 processed: true 是干嘛的。

如果加上注释，这段代码可能会失去它的“极客感”。

用“动态属性名”让代码像天书一样难懂

动态属性名是 JavaScript 的强大特性，但也可以用来制造混乱。比如：

const config = {
  [`${process.env.NODE_ENV}_API_URL`]: 'https://api.example.com',
  [`${process.env.NODE_ENV}_TIMEOUT`]: 5000,
};

这段代码的“优势”是：

没人能直接看出 config 的结构，必须运行时才知道。
如果 NODE_ENV 是 undefined，属性名会变成 undefined_API_URL，但没人会提前发现这个问题。
未来的维护者如果想加一个新环境，必须小心翼翼地确保 NODE_ENV 的值是对的。

注释？那只会让这段代码失去它的“动态魅力”。

用“隐式类型转换”制造惊喜

JavaScript 的隐式类型转换是制造“惊喜”的绝佳工具。比如：

function addToCart(item, quantity) {
  if (quantity) {
    cart.push({ ...item, quantity });
  }
}

这段代码的“精妙”之处在于：

如果 quantity 是 0，if (quantity) 会判断为 false，导致用户无法购买“零个”商品。
未来的开发者可能会花一小时调试，才发现问题出在“隐式转换”上。
如果加上 if (quantity !== undefined) 的注释，这段代码就失去了它的“趣味性”。

用“长链式调用”让调试变成噩梦

链式调用看起来很酷，但也可以让调试变得极其困难。比如：

const result = data
  .filter(x => x.active)
  .map(x => ({ ...x, score: calculateScore(x) }))
  .sort((a, b) => b.score - a.score)
  .slice(0, 10)
  .reduce((acc, curr) => ({ ...acc, [curr.id]: curr }), {});

这段代码的“艺术性”在于：

如果 calculateScore 抛错，堆栈信息只会指向 .map，而不会告诉你具体是哪条数据出了问题。
如果 data 是 undefined，错误会发生在 .filter，但你可能一开始以为是 data 没获取到。
如果未来的开发者想加一个日志，他们必须拆解整个链式调用，从而破坏代码的“流畅性”。

注释？那只会让这段代码变得“太容易调试”。

用“全局状态”让代码行为不可预测

全局状态是制造“不可维护性”的终极武器。比如：

let currentTheme = 'light';

function toggleTheme() {
  currentTheme = currentTheme === 'light' ? 'dark' : 'light';
}

function renderButton() {
  button.style.backgroundColor = currentTheme === 'light' ? '#fff' : '#000';
}

这段代码的“优势”是：