这是一个创建于 1214 天前的主题，其中的信息可能已经有所发展或是发生改变。
//写法 1 ，不满足条件跳过业务处理 for(){ if(!condition){ continue; } //businessCode } //写法 2,满足条件执行业务处理 for(){ if(condition){ //businessCode } }  | 1 RedBeanIce 2022-06-17 12:40:34 +08:00 via iPhone 分场景。绝大部分提前返回。1 |
 | 2 May725 2022-06-17 12:42:30 +08:00 更倾向于提前返回，避免嵌套 |
 | 3 TWorldIsNButThis 2022-06-17 12:54:01 +08:00 via iPhone 一般不用 for 使用语义化的迭代工具 map filter |
 | 4 yazinnnn 2022-06-17 12:57:06 +08:00  6 collection.filter { } //过滤满足条件 .map { } //执行业务,返回业务结果 .reduce { } //聚合业务结果 |
 | 5 yolee599 2022-06-17 13:01:27 +08:00 via Android 提前 return ，可以提高运行效率，代码也美观 |
 | 6 chendy 2022-06-17 13:09:47 +08:00 看内容多长…… 如果不长的话就套在写法 1 里 如果比较长就写成写法 2 提前退出 但是还有一种情况是好几个 contine / break 的（ sonar 会警告 这种情况一般就抽个方法，在方法里 return |
 | 7 newaccount 2022-06-17 13:10:01 +08:00 看情况。business 部分行数不多用 2 ，多了用 1 。但用 1 的时候可能会声明变量以去掉 not 判断，因为快速浏览时感叹号不明显导致漏看。如果感叹号左右增加空格提高可读性又得配置 checkstyle ，麻烦 |
 | 8 dcsuibian 2022-06-17 13:10:57 +08:00 喜欢第 1 种，少一层嵌套。 |
 | 9 AlekoShen 2022-06-17 13:34:45 +08:00 一般 1 不过如果判断条件复杂会用 3,4 楼的写法 |
 | 10 VeryZero 2022-06-17 13:36:40 +08:00 大多数情况肯定第一种好啊，可以显著降低阅读时的心智负担 |
 | 11 DrakeXiang 2022-06-17 13:37:52 +08:00 我一般都是 2 ，除非业务逻辑比较长，然后只有一个 condition 的情况下可能会选择 1 |
 | 12 Detector 2022-06-17 13:37:58 +08:00 第一种，不管是写起来是读起来，对我而言都舒服太多 |
 | 13 ericls 2022-06-17 13:41:32 +08:00 via iPhone |
 | 14 MakHoCheung 2022-06-17 14:14:57 +08:00 第一种是一个模式，忘了叫啥，Swift 的 guard 语句就是这样 |
 | 15 xuelu520 2022-06-17 14:17:56 +08:00 写法一吧， 第二种如果业务代码很多，很容易造成多重嵌套。 |
 | 16 buried 2022-06-17 14:23:12 +08:00 写法一，避免太多的缩进 |
 | 17 hidemyself 2022-06-17 14:23:45 +08:00 第一种，卫语句 |
 | 18 SteveWoo 2022-06-17 14:24:37 +08:00 看这个模块重不重要。 如果出错了风险大不大。 一般情况第一种。 重要场景，个人一定会 if 和 else 成对出现来实现，宁愿有一堆 if else 嵌套 for(){ if { if { } else{ } } else { if { } else{ // 根据算法多次与产品确认，这个场景就是啥也不做 } } } |
 | 19 fkname 2022-06-17 14:29:56 +08:00 排除其他条件更喜欢第二种，因为第一种加了一个非，有时候变量命名又是什么 notSuccess 之类的，再加个非脑子里就要多想一下，如果疏忽了就可能导致判断错误。 |
 | 20 exmario 2022-06-17 14:40:22 +08:00 一般选 2 ，业务流程更清晰 |
 | 21 aababc 2022-06-17 14:46:47 +08:00 我感觉我是分情况，在循环里不太喜欢使用 break ，continue, 在非循环的场景下，喜欢提前返回！ |
 | 22 yfugibr 2022-06-17 14:55:45 +08:00 看情况，一般会选用嵌套层数少的，逻辑看着清晰一点 |
 | 23 yaodong0126 2022-06-17 15:00:26 +08:00 说第一种的，一定没看过 lint 标准，我就贴个地址，自行斟酌： https://eslint.org/docs/rules/no-continue |
 | 24 zakokun 2022-06-17 15:02:42 +08:00 一般都提前返回 防止嵌套太多层 |
 | 25 fpure 2022-06-17 15:05:08 +08:00 @MakHoCheung Avoid Else, Return Early? |
 | 26 Amex 2022-06-17 15:08:00 +08:00 via iPhone 我反正从来不用 continue… |
 | 27 jorneyr 2022-06-17 15:16:07 +08:00 喜欢第一种守卫式写法，并且后面的代码也不用多一层缩进。 |
 | 28 potatowish 2022-06-17 15:19:51 +08:00 via iPhone 判断条件很多，就用第一种，判断条件少用第二种 |
 | 29 28Sv0ngQfIE7Yloe 2022-06-17 16:41:16 +08:00 目前我的代码尽量都是一次缩进，二次缩进就有阅读成本了 |
 | 30 dexterque 2022-06-17 16:59:11 +08:00 一般推荐 1 吧 |
 | 31 cnoder 2022-06-17 16:59:36 +08:00 有没有可能 他某个语言，没有 continue 0.0 |
 | 32 daimubai 2022-06-17 17:04:01 +08:00 第 1 种，可读性高。可以解放思维，continue 的就不用再管了 |
 | 33 Rache1 2022-06-17 17:04:24 +08:00 @cnoder TWIG ，虽然不算语言，是一个模板引擎，实现了自己的流程控制语句，但是就是没有 continue 和 break |
 | 34 Xusually 2022-06-17 17:04:34 +08:00 在循环里，没有特殊情况的话，我一般用 2. 但是在循环外，可以直接 return 的时候经常用 1. |
 | 35 littlewing 2022-06-17 17:06:57 +08:00 1 |
 | 36 unregister 2022-06-17 17:19:07 +08:00 via Android 用 continue 感觉有点多余 |
 | 37 libook 2022-06-17 17:25:14 +08:00 如果代码很长，提前返回可能不利于可读性；甚至建议除非有必要不写 else ，有 if 必有 else ，这样能规避一些逻辑盲区的 bug ，让任何情况都有所处理。 当然代码风格没有完全之策，最好是在每个项目的迭代过程中进行归纳整理，然后沉淀为 lint 规则。 |
 | 38 guanhui07 2022-06-17 17:47:48 +08:00 1 喜欢卫语句，减少嵌套 好看，方便维护，心智负担少点 |
 | 39 buxudashi 2022-06-17 17:51:29 +08:00 再加个 if(!!condition){} |
 | 40 Suddoo 2022-06-17 17:53:11 +08:00 via iPhone 我一般用第一种 |
 | 41 jiangzhizhou 2022-06-17 18:17:54 +08:00 这两种都可以，但是 for 一般必须被 Stream 替换。 |
 | 42 stillsilly 2022-06-17 18:23:38 +08:00 我写代码 18 年了，从没用过 continue |
 | 43 unco020511 2022-06-17 18:48:04 +08:00 我喜欢 1 |
 | 44 kinghly 2022-06-18 00:19:49 +08:00 via Android 减少嵌套 |
 | 45 clorischan 2022-06-18 03:20:11 +08:00 1 个人习惯是循环内用真判断, 满足条件时执行. 函数内使用假判断, 参数不符合要求提前返回. 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 } } } |
 | 46 lujiaosama 2022-06-18 08:42:46 +08:00 循环外第一种提前返回, 循环内第二种我不喜欢用 continue |
 | 47 icylogic 2022-06-18 11:08:39 +08:00 第一种视觉上嵌套少，但 npath 复杂度仍然是升高的，函数最终还是要控制 npath （或者类似的标准）以适配人脑 cache 大小 |
 | 48 a68UkLHpycW7ImyV 2022-06-18 12:00:21 +08:00 via Android 大部分情况下都是第 1 种 |
 | 49 wu67 2022-06-18 14:41:14 +08:00 建议看看《重构》, 有对这个场景的说明. 按我个人理解, 是分支少就直接 if else. if else 过多, 需要打断嵌套地狱, 就使用‘错误先行’, 即提前返回, 后续的代码就能少一层{} |
 | 50 cheng6563 2022-06-18 15:10:42 +08:00 哪种{}小用哪种 |
 | 51 evan1024 2022-06-18 19:23:08 +08:00 via Android 一般保持团队一致即可，推荐引入代码风格检查工具 |
 | 52 irisdev 2022-06-18 21:10:59 +08:00 2 吧，不喜欢用 continue |
 | 53 changz 2022-06-19 16:55:25 +08:00 卫语句 |
 | 54 alen0206 2022-06-24 14:49:48 +08:00 1 |
 | 55 siweipancc 2022-07-14 11:59:38 +08:00 via iPhone 第二种容易写成无限套娃，看得人头大。 我写的业务代码缩进超过两次就当场重构了。 我的猜想是喜欢第二种的大部分原因来源产品模糊的需求，那怎么避免呢？ if 判断精确判断到产品的原话不就得了，好处是出问题直接甩锅，至于代码维护的相信后人智慧 |
Select Language