讨论一个业务代码判断的写法问题，这两种写法你们更喜欢那种？

[nuanshen]

//写法 1 ，不满足条件跳过业务处理
for(){
  if(!condition){
    continue;
  }
  //businessCode
}

//写法 2,满足条件执行业务处理
for(){
  if(condition){
    //businessCode
  }
}

[RedBeanIce]

分场景。绝大部分提前返回。1

[May725]

更倾向于提前返回，避免嵌套

[TWorldIsNButThis]

一般不用 for
使用语义化的迭代工具
map filter

[yazinnnn]

collection.filter { } //过滤满足条件
.map { } //执行业务,返回业务结果
.reduce { } //聚合业务结果

[yolee599]

提前 return ，可以提高运行效率，代码也美观

[chendy]

看内容多长……
如果不长的话就套在写法 1 里
如果比较长就写成写法 2 提前退出

但是还有一种情况是好几个 contine / break 的（ sonar 会警告
这种情况一般就抽个方法，在方法里 return

[newaccount]

看情况。business 部分行数不多用 2 ，多了用 1 。但用 1 的时候可能会声明变量以去掉 not 判断，因为快速浏览时感叹号不明显导致漏看。如果感叹号左右增加空格提高可读性又得配置 checkstyle ，麻烦

[dcsuibian]

喜欢第 1 种，少一层嵌套。

[AlekoShen]

一般 1 不过如果判断条件复杂会用 3,4 楼的写法

[VeryZero]

大多数情况肯定第一种好啊，可以显著降低阅读时的心智负担

[DrakeXiang]

我一般都是 2 ，除非业务逻辑比较长，然后只有一个 condition 的情况下可能会选择 1

[Detector]

第一种，不管是写起来是读起来，对我而言都舒服太多

[ericls]

@yazinnnn 有些语言这样写会产生实际的性能问题 虽然看起来比较舒服

我个人喜欢第一种 但是你要写成别的 我也没意见

[MakHoCheung]

第一种是一个模式，忘了叫啥，Swift 的 guard 语句就是这样

[xuelu520]

写法一吧，
第二种如果业务代码很多，很容易造成多重嵌套。

[buried]

写法一，避免太多的缩进

[hidemyself]

第一种，卫语句

[SteveWoo]

看这个模块重不重要。 如果出错了风险大不大。 一般情况第一种。
重要场景，个人一定会 if 和 else 成对出现来实现，宁愿有一堆 if else 嵌套
for(){
if {
if {
} else{
}
} else {
if {
} else{
// 根据算法多次与产品确认，这个场景就是啥也不做
}
}
}

[fkname]

排除其他条件更喜欢第二种，因为第一种加了一个非，有时候变量命名又是什么 notSuccess 之类的，再加个非脑子里就要多想一下，如果疏忽了就可能导致判断错误。

[exmario]

一般选 2 ，业务流程更清晰

[aababc]

我感觉我是分情况，在循环里不太喜欢使用 break ，continue, 在非循环的场景下，喜欢提前返回！

[yfugibr]

看情况，一般会选用嵌套层数少的，逻辑看着清晰一点

[yaodong0126]

说第一种的，一定没看过 lint 标准，我就贴个地址，自行斟酌： https://eslint.org/docs/rules/no-continue

[zakokun]

一般都提前返回 防止嵌套太多层

[fpure]

@MakHoCheung Avoid Else, Return Early?

[SeaTac]

我反正从来不用 continue…

[jorneyr]

喜欢第一种守卫式写法，并且后面的代码也不用多一层缩进。

[potatowish]

判断条件很多，就用第一种，判断条件少用第二种

[28Sv0ngQfIE7Yloe]

目前我的代码尽量都是一次缩进，二次缩进就有阅读成本了

[dexterque]

一般推荐 1 吧

[cnoder]

有没有可能 他某个语言，没有 continue 0.0

[daimubai]

第 1 种，可读性高。可以解放思维，continue 的就不用再管了

[Rache1]

@cnoder TWIG 😂，虽然不算语言，是一个模板引擎，实现了自己的流程控制语句，但是就是没有 continue 和 break

[Xusually]

在循环里，没有特殊情况的话，我一般用 2.

但是在循环外，可以直接 return 的时候经常用 1.

[littlewing]

1

[unregister]

用 continue 感觉有点多余

[libook]

如果代码很长，提前返回可能不利于可读性；甚至建议除非有必要不写 else ，有 if 必有 else ，这样能规避一些逻辑盲区的 bug ，让任何情况都有所处理。

当然代码风格没有完全之策，最好是在每个项目的迭代过程中进行归纳整理，然后沉淀为 lint 规则。

[guanhui07]

1 喜欢卫语句，减少嵌套 好看，方便维护，心智负担少点

[buxudashi]

再加个
if(!!condition){}

[Suddoo]

我一般用第一种

[jiangzhizhou]

这两种都可以，但是 for 一般必须被 Stream 替换。

[stillsilly]

我写代码 18 年了，从没用过 continue

[unco020511]

我喜欢 1

[kinghly]

减少嵌套

[clorischan]

个人习惯是循环内用真判断, 满足条件时执行.
函数内使用假判断, 参数不符合要求提前返回.
e.g:
DoSomethings (things)
{
if (things is null) throw
if (things is empty) return

for (thing in things)
{
if (thing is not nothing)
{
//do thing
}
}
}

[lujiaosama]

循环外第一种提前返回, 循环内第二种我不喜欢用 continue

[icylogic]

第一种视觉上嵌套少，但 npath 复杂度仍然是升高的，函数最终还是要控制 npath （或者类似的标准）以适配人脑 cache 大小

[a68UkLHpycW7ImyV]

大部分情况下都是第 1 种

[wu67]

建议看看《重构》, 有对这个场景的说明.
按我个人理解, 是分支少就直接 if else.
if else 过多, 需要打断嵌套地狱, 就使用‘错误先行’, 即提前返回, 后续的代码就能少一层{}

[cheng6563]

哪种{}小用哪种

[evan1024]

一般保持团队一致即可，推荐引入代码风格检查工具

[irisdev]

2 吧，不喜欢用 continue

[changz]

卫语句

[alen0206]

1

[siweipancc]

第二种容易写成无限套娃，看得人头大。
我写的业务代码缩进超过两次就当场重构了。

我的猜想是喜欢第二种的大部分原因来源产品模糊的需求，那怎么避免呢？ if 判断精确判断到产品的原话不就得了，好处是出问题直接甩锅，至于代码维护的相信后人智慧