经常在代码里看到这种用法
// 关闭某个接口
if(true) { return APIResultVo.error(xxxx); }
这个 if( true ) 是什么编程习惯?有什么说法么?
1
gigantic222 2017-08-11 09:03:44 +08:00 via iPhone
不加逻辑不舒服斯基
|
2
ericls 2017-08-11 09:03:48 +08:00 via iPhone
以前需要判断 现在不需要了
|
3
blankme 2017-08-11 09:05:22 +08:00
注释都告诉你了。。。
|
4
Rice 2017-08-11 09:05:31 +08:00
多半是懒得删除 if 语句结构
|
5
veelog 2017-08-11 09:06:34 +08:00 via iPhone
我喜欢用 do{}while(0)
|
6
facetest 2017-08-11 09:06:43 +08:00 via Android
软删除
|
7
littleylv 2017-08-11 09:07:20 +08:00 24
不是懒。是为了防止以后又要改回去
|
8
syncher 2017-08-11 09:09:45 +08:00 via Android
难道是被产品逼的?
|
9
play78 2017-08-11 09:11:15 +08:00
业务写多了, 你如果看到这种代码,也见惯不怪了。
boolean flag = check(model); //检查模型部分参数及功能合法性 flag = true; //由于 XXX 需求修改 if(flag == true){ //do something }else{ //do other } |
10
congeec 2017-08-11 09:15:15 +08:00
我也喜欢这样,不过吃过不少亏
记得旁边加个注释,// FIXME |
11
DrJoseph 2017-08-11 09:16:18 +08:00 9
这叫防御性开发,防止需求的多次更改
|
12
littleylv 2017-08-11 09:16:43 +08:00
@play78 #8
你这样改问题很大。。。。。。不应该继续执行 check 方法了。 boolean flag = true; //check(model); //检查模型部分参数及功能合法性 // 20170811 由于 XXX 需求修改 我一般会这样改。保持原来的代码在,但注释掉,不要再执行。你懂的万一需求脑抽又要改回去,不能删掉 check 的代码 |
13
LeoNG 2017-08-11 09:21:05 +08:00
好像在哪见过,/t/375091
|
14
ThatIsFine 2017-08-11 09:21:09 +08:00
开关要么是配置,要么常量. 直接这么写也就 DEBUG 的时候.发版的时候还有这种就不太专业.
|
15
Mutoo 2017-08-11 09:25:47 +08:00 3
我喜欢用注释
//* this block is for test console.log('this line would be output'); //*/ 不用的时候删除掉第一个 / /* console.log('this line would not'); //*/ 另外还有两个代码块切换的用法 //* console.log('run this'); /*/ console.log('or this'); //*/ |
16
SourceMan 2017-08-11 09:27:36 +08:00 2
防御性开发,他是一个老司机,你要跟他学习
|
17
miniwade514 2017-08-11 09:29:39 +08:00 2
很早以前看过的一篇文章
http://www.bitnative.com/2012/10/22/kill-the-zombies-in-your-code/ 一直记得他的核心观点:不用就删,别不舍得 “说不准哪天会用到”的东西,十有八九是再也用不到了,或者很久很久才会用到。而这些注释代码对于后续开发是一种干扰,尤其是交给其他人时。 真要保留 A/B 两种方案时,可以尝试分别封装到模块或者函数里,代码干净很多。 |
18
miniwade514 2017-08-11 09:31:42 +08:00
如果是开发过程中临时 mock,我一般会加上注释
// TODO 调试用,上线前删掉 |
19
raiz 2017-08-11 09:32:08 +08:00
调试到不用调试了。
|
20
VincentWang 2017-08-11 09:32:30 +08:00 1
那些说需求来回改的,你们代码不用版本控制吗? 老代码在版本里,不要的代码就删了啊...
|
21
Perry 2017-08-11 09:35:37 +08:00 via iPhone
好奇怎么通过 code review 的 还什么防御性开发 牛逼
|
23
nicevar 2017-08-11 09:44:34 +08:00
@VincentWang 版本控制如果改动多的话时间一长几十个版本去找浪费时间,而且代码逻辑复杂的情况下更麻烦,上面说的,写 fixme+注释比较妥当
|
24
hiboshi 2017-08-11 09:46:06 +08:00
我们也经常这样 ,有时候需要 临时关闭 某个功能,我的经验是 老代码写成这样 往往都是有原因的。
|
25
shard 2017-08-11 09:49:58 +08:00
骗编译器?
比如 ``` if(true) return xxx; // other codes ... ``` |
26
Lucups 2017-08-11 09:50:41 +08:00 5
|
27
stephen9357 2017-08-11 10:13:34 +08:00
@littleylv 这样做是过不了代码覆盖率检查的。
|
28
fan123199 2017-08-11 10:29:18 +08:00
如果不加 if,return 下面如果有代码,有些 ide 会报错
|
29
bk201 2017-08-11 10:40:01 +08:00
代码少还好,多了看得是比较烦人的。
|
30
loveCoding 2017-08-11 10:43:30 +08:00
防御性开发最多做个为空判断 ,其他代码都删掉吧 ,基本上用不到.
|
31
ma125125t 2017-08-11 10:45:29 +08:00
上面说 code review、版本控制的,纯粹是你们的需求改的不够多罢了。
当然,我承认这样写不好。 |
32
jason2017 2017-08-11 10:50:04 +08:00
还什么防御性开发,代码不规范就是不规范,懒就是懒。
所谓的为了防止需求变动,你就那 2 行代码改起来都觉得费事吗? 而且对于经常变动的业务,也不应该写这种硬编码的代码,更应该考虑把相关逻辑转移到配置文件或者数据库中,这才是"防御性开发"。 |
33
mcfog 2017-08-11 10:50:39 +08:00
|
35
pynix 2017-08-11 10:55:24 +08:00
当注释用吧,,,
|
36
esmdxx1 2017-08-11 11:04:13 +08:00 via Android
楼主你用你得先夺为主得偏见,首先就确定事情得结构,事实上得情况 ,复杂很多,所以原因也太多,比如,自己定义得条件编译,或者本来需要两段代码,
|
37
gdtv 2017-08-11 11:05:15 +08:00
我承认我这样写不规范,但需求更不规范,如果需求能保证始终如一后续不改变,我保证能写出规范的代码。
|
38
flowci 2017-08-11 11:15:00 +08:00 3
不要滥用概念,,,,防御性编程是一种编程习惯,是指预见在什么地方可能会出现问题,然后创建一个环境来测试错误,当预见的问题出现的时候通知你,并执行一个你指定的损害控制动作,如停止程序执行,将用户重指向到一个备份的服务器,或者开启一个你可以用来诊断问题的调试信息。。。。
|
40
iyaozhen 2017-08-11 11:20:29 +08:00 via Android
说实话没有见到过这样的代码,写过的、review 过的代码也有十几万行了。这样些是会被直接打回的
|
41
weer0026 2017-08-11 11:21:20 +08:00
强迫症表示每次都删。。
|
42
broker 2017-08-11 11:30:16 +08:00 1
是为了增加一个 block 吧,if(true) 比直接写{ },可读性强一些。。。 就像用 do {} while(false)代替 goto
|
43
esmdxx1 2017-08-11 11:30:25 +08:00 via Android
屏蔽我得记忆,测试什么啊
|
44
hyyou2010 2017-08-11 11:30:39 +08:00
比如某一段代码不需要了,但没准明天又需要了,可以这样临时处理一下。不方便注释掉,因为可能导致其他地方编译不过,一路都处理比较费劲。
|
45
esmdxx1 2017-08-11 11:33:04 +08:00 via Android
铺天盖地得测试,你们告诉我你们是为了让我不回应,而还发铺天盖地得测试
|
46
autoxbc 2017-08-11 11:52:11 +08:00
代码是需求的流程化描述,如果需求本身是混沌的,代码强行清晰说明丢失了信息
|
48
autoxbc 2017-08-11 11:56:03 +08:00
比如产品说,这个到底怎么弄我还没想到,你的代码要体现出这种内心的纠结
|
49
sampeng 2017-08-11 12:04:40 +08:00
原来大家 git/svn 都不怎么用的。。。为毛不直接删。如果真可能有用,打个 tag。要的时候从版本库里面找回来也就分分钟的事
|
50
gamexg 2017-08-11 12:04:42 +08:00
如果觉得这个功能以后都不用了当然会删除 if。
但是有时候明知需求不靠谱,几天后还会改回来,就不删除 if,只修改下条件,方便下次找准地方(版本库回退是个方法,但是回退前还会有其他提交,回退不方便)。 不过如果这个功能没回退,那么 if(true) 可能就忘记导致永久留在那里了。 |
52
kfll 2017-08-11 12:37:04 +08:00 via Android
这样就不用改缩进了呀
|
53
elgae 2017-08-11 12:38:59 +08:00
条件编译。没啥用,编译时优化就把 if 去掉了
|
54
mkdong 2017-08-11 12:44:26 +08:00 via iPhone
只见过 if (false) 配合 goto
|
55
mawenjian 2017-08-11 12:56:27 +08:00 via iPhone
控制内部变量的作用域,这样写还是有点用的。
|
56
wzha2008 2017-08-11 12:58:50 +08:00
if check_condition and 0:
pass if check_condition or 1: pass |
57
bolice 2017-08-11 13:39:25 +08:00
我经常这样写,当测试环境不满足时
if(true)//(实际判断条件) { } else { } 完事正事测试时删掉 (true)// |
59
afpro 2017-08-11 13:54:30 +08:00 via Android
楼上不要瞎说 这个人明显是想干掉这个方法 直接返回 error 但是不会 aop 又不想靠 git 不敢删代码 直接写个 return 编译器又不高兴 只好用 if(true) 包起来了
|
60
ty89 2017-08-11 14:35:21 +08:00
预留的
这个地方很有可能将来变成由某个条件决定,因此写成 if 结构 |
61
xiaowangge 2017-08-11 14:36:29 +08:00
你们公司有 code review 吗?/t/291623
|
62
xiaowangge 2017-08-11 14:36:58 +08:00
|
63
fhefh 2017-08-11 15:03:19 +08:00
true 以前应该放了什么条件 由于某些原因又不需要了 以后可能还要 所以 就这么放着了
话说偶经常这么干~~ |
64
flyingghost 2017-08-11 15:48:43 +08:00
@autoxbc 体现内心的纠结 233333333333
|
65
nosugar 2017-08-11 15:59:42 +08:00
https://github.com/barrer/scan-helper/blob/master/scan_helper_jpg.py
写了好几个: if True: # 禁用灰度设置 colorspace = '' depth = ' -depth 8' # https://en.wikipedia.org/wiki/Color_depth if True: # 禁用色彩深度 depth = '' 主要是防止有人要用的时候直接设置“ False ”,方便,防御性开发 |
66
linpf 2017-08-11 16:29:27 +08:00
对我来说,出现这种情况的可能性就是预留。
在短期的未来时间内,我需要在这里加个条件,但是目前还不需要。 |
67
xuboying 2017-08-11 16:43:53 +08:00 via Android
这是在给项目经理留台阶啊,毕竟拍脑袋的人不会理解重构,重新代码 review,从 git 历史找代码重新融合都要花时间的。
|
68
xuboying 2017-08-11 16:44:52 +08:00 via Android
薛定谔的代码
|
70
huluhulu 2017-08-11 17:37:51 +08:00
这种一般上
#ifdef xxxx { } #endif |
71
jalena 2017-08-11 17:39:47 +08:00
感觉这很正常啊!!经常条件函数没有写完的时候直接就用 true 来跑了 啊,等那边写好直接改就好了嘛!!
|
72
superkey 2017-08-11 17:58:25 +08:00
测试呀,我喜欢这样.
``` if(... || 1) { xxx } ``` |
73
Matrixbirds 2017-08-11 18:30:04 +08:00
可能是遇到了假的 true
|
74
CruelMoon 2017-08-11 18:31:56 +08:00
调试的需要
|
75
omygod 2017-08-11 18:41:21 +08:00
可读性高啊
|
76
wohenyingyu01 2017-08-11 19:13:53 +08:00
@dorentus 新的编译器应该直接不编译这个判断,这才是优化吧。
|
77
sacuba 2017-08-11 19:17:58 +08:00
@VincentWang #20 一个需求改个十几次二十几次的,你会发现版本根本没用的!!!
|
78
Afanyiyu 2017-08-11 19:24:44 +08:00
iftrue 应该就是 debug 用的吧,
不过要是 jit 编译的话有没有都一样, 不过,,,美观呢? |
79
ryd994 2017-08-11 20:59:47 +08:00
if true
为什么不用#define ? 孤零零一个 true,谁知道什么用 |
83
yankebupt 2017-08-11 23:23:35 +08:00
可能是为了调试
我记得有一种上古语言 return 上不能加断点还是 return 上加断点会 bug 来的...... 如果这个是继承了那个编程习惯.... 这个 if(true)可能功能只是个行号,用来放一个断点在上面看变量内容的.... |
84
ety001 2017-08-12 00:33:48 +08:00
@VincentWang #20
23 楼说的很对,如果代码逻辑很复杂,你往回找好几个版本,真的是很痛苦。不如直接注释掉,写好备注信息。 |
85
chenyu0532 2017-08-12 09:26:45 +08:00
这没什么吧,我开发游戏的时候可能需要有一些测试的场景,我换下 true 和 false 就能直接在正式和测试的场景互换了啊。。或许有更牛逼的写法。。请赐教、、、
|
86
VincentWang 2017-08-12 11:31:26 +08:00
|
87
ety001 2017-08-12 13:16:17 +08:00
@VincentWang #86 理想状态是这样,但是很多时候,在外包这个行业里,需求的变动快速,很可能一个改动就一个 commit 的话,会疯掉。
|
88
ssxn58 2017-08-12 15:55:32 +08:00
#if DO_XXXXXXX
..... #else ..... #endif |