嗨，这种代码风格的纠结我太熟了——刚入行的时候也因为嵌套if和括号的问题被评审卡过好几次！咱们慢慢拆解你的两个疑问：

一、嵌套if vs 连续else if：为啥评审更推荐后者？ #

先看你提交的原代码：

if(a) {
  code=a;
} else {
   if(b){
    code=b;
   }else{
    code=c;
   }
}

改成else if的版本：

if(a) {
  code=a;
} else if(b) {
  code=b;
} else {
  code=c;
}

这两种写法逻辑上完全等价，但评审更偏好后者的核心原因是可读性：

• 视觉上更扁平，一眼就能看出这是「三选一」的分支判断，而不是先判断a，再在else块里做另一个独立的嵌套判断
• 减少了不必要的缩进层级，后续维护的人不容易看错分支归属

你同事说这是「不同的命令」其实表述有点偏差——本质是代码结构的可读性差异，评审的核心是让团队代码风格统一，同时降低所有人的理解成本。

二、关于if/else的括号省略规则：为啥else的括号能省？ #

先明确绝大多数C系语言（JS/Java/C#等）的语法规则：

如果if/else后面紧跟的是单条语句（哪怕这条语句是另一个完整的if-else块），语法上允许省略大括号；如果是多条语句，必须加括号。

回到你的疑问：「单条if可以省括号，else为啥也能省？」
其实else的规则和if完全一致——你原代码里的else后面跟着的是一个完整的if(b){...}else{...}，这在语法上属于一条复合语句，所以可以省略else的大括号。

但这里必须提醒：省略括号是语法允许，但几乎所有成熟团队都会禁止这么做！
举个反例：如果后续有人在else块里加了一行代码，忘了补括号：

if(a) {
  code=a;
} else 
  if(b){
    code=b;
  }else{
    code=c;
  }
  // 新加的代码：
  console.log("done");

这时候console.log会脱离else块，变成独立执行的代码，直接引入隐蔽的bug。所以很多团队会强制要求所有if/else块都加括号，哪怕只有一行代码——这是为了从根源上避免这种低级但致命的错误。

最后给你个小提示 #

既然评审提出了格式要求，按团队统一风格改就行——代码风格从来不是「谁对谁错」，而是团队共识优先。如果对规则有疑问，直接在评审里问同事「咱们团队有没有成文的风格指南？」，这样后续就不会踩类似的坑啦～