在条件语句中赋值变量是否可取？附对象属性累加代码对比

嘿，这个问题问得挺实在的——在条件逻辑里嵌入变量赋值，算不算合理的编程实践？其实答案不是非黑即白的，得结合可读性、团队共识和潜在的逻辑陷阱来看。咱们先拆解你给出的两种累加对象属性的写法，再聊这个核心问题。

第一种：短路逻辑赋值写法 #

先看这段代码：

((sum[key] += obj[key]) || (sum[key] = obj[key]))

逻辑原理 #

它利用了JavaScript的短路求值特性：

• 如果sum[key]已经存在且是有效的数字（非undefined/NaN），sum[key] += obj[key]会返回累加后的数值（truthy值），后面的sum[key] = obj[key]就不会执行；
• 如果sum[key]不存在（undefined），sum[key] += obj[key]会得到NaN（falsy值），此时短路逻辑会执行后半段的赋值，把sum[key]设为obj[key]。

优劣点 #

• 优点：代码非常简洁，一行就能完成判断+赋值的逻辑；
• 缺点：
  1. 可读性差：对不熟悉JS短路求值的开发者来说，这段代码像“黑魔法”，得花时间拆解逻辑，维护成本高；
  2. 潜在陷阱：如果sum[key]的有效值是falsy值（比如0），虽然在这个累加场景下不会出问题，但如果业务逻辑变化，比如允许累加0以外的falsy值，就可能出现意外覆盖；
  3. 调试不便：出现问题时，很难直接通过断点快速定位逻辑分支。

第二种：三元运算符写法 #

再看这段代码：

sum[key] = typeof sum[key] != "undefined" ? sum[key] + obj[key] : obj[key]

逻辑原理 #

它直白地做了判断：先检查sum[key]是否已定义，如果是就累加，否则直接赋值obj[key]。逻辑完全透明，没有隐藏的语法技巧。

优劣点 #

• 优点：
  1. 可读性拉满：哪怕是刚入门的JS开发者，也能一眼看懂这段代码的意图；
  2. 无隐藏陷阱：逻辑分支清晰，不会因为falsy值的出现导致意外行为；
  3. 调试友好：断点时能直接看到判断条件的结果，容易排查问题。
• 缺点：代码比第一种稍长一点，但这点长度换可读性完全值得。

核心问题解答：条件语句内赋值算不算合理实践？ #

在JavaScript生态里，用短路逻辑做赋值是常见的惯用写法（比如const foo = bar || defaultValue），但这并不意味着它在所有场景下都合理：

• 如果团队成员都熟悉这种语法，且代码逻辑简单（比如简单的默认值赋值），那它是高效的写法；
• 如果是复杂业务逻辑，或者团队里有不少新手，那可读性优先，像三元运算符这种直白的写法更合适。

更推荐的现代JS写法 #

其实ES2020之后，咱们有了更简洁且清晰的写法，比如用空值合并运算符（??）：

objs.forEach(obj => {
  Object.keys(obj).forEach(key => {
    // 先给sum[key]设置默认值0（如果它是undefined/null的话），再累加
    sum[key] = (sum[key] ?? 0) + obj[key];
  });
});

或者拆分两步，更清晰：

objs.forEach(obj => {
  Object.keys(obj).forEach(key => {
    // 如果sum[key]未定义，先设为0
    sum[key] ??= 0;
    // 再累加
    sum[key] += obj[key];
  });
});

这种写法既保留了简洁性，又完全避免了短路逻辑的歧义，可读性和健壮性都拉满。

内容的提问来源于stack exchange，提问作者Below the Radar