这是一个创建于 2680 天前的主题，其中的信息可能已经有所发展或是发生改变。
经常在代码里看到这种用法
// 关闭某个接口
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 |
Select Language