大家写代码时喜欢用 Guard Clause 还是一条路径走到底？

[agagega]

前两天 Code Review 的时候被指出了这个问题。

如题，是

bool func() {
  if (xxx) return false;
  if (xxx) return true;
  xxx;
  return true;
}

还是

bool func() {
  if (xxx) {
    if (xxx) return false;
    else return true;
  } else {
    xxx;
    return true;
  }
}

好像前者一般比较清爽，缩进层次也少。我只看过王垠在他的博客里强烈支持过第二种。

[blueskit]

王垠为什么支持呢？

[VVVVVEX]

你给的两个例子，逻辑都不一样。
至于使用那种形式，还是看逻辑啊。
如果是并列条件，使用第一种，如果是前提条件，使用前套逻辑。这样的代码符合人类的思维，好懂。
王垠又不是啥权威，写文章很多，无论是工业产品，还是开源项目，并没有什么建树，并不觉得他说什么就有道理。
我觉得除了 80 列是个铁律，别的都不是完全的定死的。

[df4VW]

Guard 有时候会因为逻辑 上没思考全导致部分条件没有覆盖而进入之后的代码流程，强制 if else 2 分能确保覆盖所有情况，养成习惯之后能保证处理到所有 case，不管是有意还是无意。再加上王垠用的是 java，用 if else ide 能提示有些 case 没处理

用这种习惯之后几乎没有负担的被动技能来减少代码出错的可能性其实也是比较务实的做法

[1010011010]

我喜欢第一种，过程比较清晰

[sugarsalt]

case 多的话，switch

[lightening]

代码首先要反映程序员的逻辑，怎么想就怎么写。

两种常见情景：

1 ）写到这里，哎呀这个变量如果是 b 就不对了，先 return 掉
2 ）写到这里，发现有以下两种可能的情况

显然 1 ）应该用 early return，2 ）应该用 if else

[watzds]

@VVVVVEX 80 列算什么铁律，那是以前的显示器一行只能显示这么多，现在 120 也没问题

[tamlok]

@watzds 左右分屏的时候你就知道 80 好还是 120 好。而且 80 还有另一个意义，间接地控制代码的嵌套层级。

[jatesun]

第一种，第二种可读性不高

[jorneyr]

bool func() {
if (xxx) { return false };
if (xxx) { return true };
xxx;
return true;
}

[Nick66]

一会简写一会不简写最恶心

[whileFalse]

if (xxx) return false;
else return true;

这个代码太骚了。

[VVVVVEX]

GCC LLVM
Linux *BSD
QEMU
Python Django
node
Vim
Firefox Chrome
React
Rust
这些项目都是遵循 80 列，有比 90 后年龄大的，也有比 90 后年轻的。
别的项目我不太清楚，gayhub 上的总会有很多超过 80 列的个人项目，数量上一定是取胜的。

[crayygy]

就你提供的代码风格来看，这第二种写出来会被打的...不管哪种语言，if else 还是尽量都应该括号保证有合理的 scope，也方便以后添加逻辑，除非是保护性的代码，if ==null return 这种我觉得不需要括号，直接一行话搞定。

[liuxey]

第二种是真的神奇，一会有括号，一会没括号，而且逻辑和第一个也不一样，我更喜欢 #10 的写法

[sagaxu]

10 个变量二分就是 1024 种组合，来个 10 层嵌套吗？

形式上的完整覆盖，和逻辑上的完整覆盖，目的是哪个？

[chenyu8674]

跟代码没关系，本质上还是看写代码的人怎么理解这段判断关系

[zarte]

第二种，
只返回一个的时候第一种

[watzds]

@tamlok 我不觉得 120 就比 80 好，只是觉得这不是铁律

[qY3209HZitEb5Zty]

```
bool func() {
if (xxx) {
return xxx ? false : true;
}

xxx;
return true;
}
```

[Chieh]

原则上用第二种，如果较短的 if else 两行能放下的话就用第一种

[feiyuanqiu]

@jjzhanhun return xxx ? false : true;

xxx 的运算结果本来就是个 bool，为什么还要用三目运算符再处理一次？

[akira]

前面的 嵌套越少越好

[ConradG]

分支多，或分支条件琐碎的，多用第一种。
分支少，尤其二择多用第二种。

[cuzfinal]

第一种避免箭头形代码。

[newtype0092]

第二种逻辑更完整，不过可读性差，需要配合 ide 检查，个人觉得这种更适合自动生成而不是手动去写。
手写代码还是用第一种更合理，逻辑更清楚，而且一定程度上能反应写代码的思路。

有些人觉得第二种写法这样的冗余工作有助于减少出错，但我认为如果手写这种代码的话眼花出错的概率更高，而且看的头大干扰了自己的思路更容易写错。

人的思考还是应该求巧，求全是靠各种重复冗余来保证，这是机器该做的，与其不辞辛劳去做冗余工作，不如造一个机器帮自己偷懒。

[agagega]

@VVVVVEX 其实一般的新一点的项目我觉得 108 或者 120 字符都可以接受，风格统一的问题。

[agagega]

@liuxey
@crayygy
确实，这里只是举个例子，还是都带花括号的好

[AltairT]

王垠的文章我看过，貌似不是你第二种那样。他明明说了类似意思的话 1 避免箭头代码的方法是将条件反转，提前返回（就是你说的防御代码）;2 为了防止遗漏情况，有 if 就必须有 else。
这两条也不矛盾啊。还是你没理解清楚

[pynix]

前期可能会先走逻辑(约定参数都有效)，，，，后期会慢慢加参数验证。。。

[morethansean]

第一种，当年写 WE 养成的习惯 2333333

[luozic]

直接 if，如果分支切分覆盖不对，还不是一样坑。