经常在代码里看到这种用法
// 关闭某个接口
if(true) { return APIResultVo.error(xxxx); }
这个 if( true ) 是什么编程习惯？有什么说法么？
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 3378 days ago, the information mentioned may be changed or developed.
 |
gigantic222Aug 11, 2017 via iPhone
1
不加逻辑不舒服斯基
|
 |
ericlsAug 11, 2017 via iPhone
2
以前需要判断 现在不需要了
|
 |
blankmeAug 11, 2017
3
注释都告诉你了。。。
|
 |
RiceAug 11, 2017
4
多半是懒得删除 if 语句结构
|
 |
veelogAug 11, 2017 via iPhone
5
我喜欢用 do{}while(0)
|
 |
facetestAug 11, 2017 via Android
6
软删除
|
 |
7
不是懒。是为了防止以后又要改回去
|
24 |
syncherAug 11, 2017 via Android
8
难道是被产品逼的？
|
 |
play78Aug 11, 2017
9
业务写多了， 你如果看到这种代码，也见惯不怪了。
boolean flag = check(model); //检查模型部分参数及功能合法性 flag = true; //由于 XXX 需求修改 if(flag == true){ //do something }else{ //do other } |
 |
congeecAug 11, 2017
10
我也喜欢这样，不过吃过不少亏
记得旁边加个注释，// FIXME |
 |
11
这叫防御性开发，防止需求的多次更改
|
|
U7Q5tLAex2FI0o0gAug 11, 2017
12
@play78 #8
你这样改问题很大。。。。。。不应该继续执行 check 方法了。 boolean flag = true; //check(model); //检查模型部分参数及功能合法性 // 20170811 由于 XXX 需求修改 我一般会这样改。保持原来的代码在，但注释掉，不要再执行。你懂的万一需求脑抽又要改回去，不能删掉 check 的代码 |
 |
LeoNGAug 11, 2017
13
好像在哪见过，/t/375091
|
 |
ThatIsFineAug 11, 2017
14
开关要么是配置,要么常量. 直接这么写也就 DEBUG 的时候.发版的时候还有这种就不太专业.
|
 |
15
我喜欢用注释
//* 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
防御性开发，他是一个老司机，你要跟他学习
|
 |
17
很早以前看过的一篇文章
http://www.bitnative.com/2012/10/22/kill-the-zombies-in-your-code/ 一直记得他的核心观点：不用就删，别不舍得 “说不准哪天会用到”的东西，十有八九是再也用不到了，或者很久很久才会用到。而这些注释代码对于后续开发是一种干扰，尤其是交给其他人时。 真要保留 A/B 两种方案时，可以尝试分别封装到模块或者函数里，代码干净很多。 |
|
miniwade514Aug 11, 2017
18
如果是开发过程中临时 mock，我一般会加上注释
// TODO 调试用，上线前删掉 |
 |
raizAug 11, 2017
19
调试到不用调试了。
|
 |
20
那些说需求来回改的，你们代码不用版本控制吗？ 老代码在版本里，不要的代码就删了啊...
|
 |
PerryAug 11, 2017 via iPhone
21
好奇怎么通过 code review 的 还什么防御性开发 牛逼
|
 |
nicevarAug 11, 2017
23
@VincentWang 版本控制如果改动多的话时间一长几十个版本去找浪费时间，而且代码逻辑复杂的情况下更麻烦，上面说的，写 fixme+注释比较妥当
|
 |
hiboshiAug 11, 2017
24
我们也经常这样 ，有时候需要 临时关闭 某个功能，我的经验是 老代码写成这样 往往都是有原因的。
|
 |
shardAug 11, 2017
25
骗编译器？
比如 ``` if(true) return xxx; // other codes ... ``` |
 |
26
|
 |
stephen9357Aug 11, 2017
27
@littleylv 这样做是过不了代码覆盖率检查的。
|
 |
fan123199Aug 11, 2017
28
如果不加 if，return 下面如果有代码，有些 ide 会报错
|
 |
bk201Aug 11, 2017
29
代码少还好，多了看得是比较烦人的。
|
 |
loveCodingAug 11, 2017
30
防御性开发最多做个为空判断 ,其他代码都删掉吧 ,基本上用不到.
|
 |
ma125125tAug 11, 2017
31
上面说 code review、版本控制的，纯粹是你们的需求改的不够多罢了。
当然，我承认这样写不好。 |
 |
jason2017Aug 11, 2017
32
还什么防御性开发，代码不规范就是不规范，懒就是懒。
所谓的为了防止需求变动，你就那 2 行代码改起来都觉得费事吗？ 而且对于经常变动的业务，也不应该写这种硬编码的代码，更应该考虑把相关逻辑转移到配置文件或者数据库中，这才是"防御性开发"。 |
 |
mcfogAug 11, 2017
33
|
 |
pynixAug 11, 2017
35
当注释用吧，，，
|
 |
esmdxx1Aug 11, 2017 via Android
36
楼主你用你得先夺为主得偏见，首先就确定事情得结构，事实上得情况 ，复杂很多，所以原因也太多，比如，自己定义得条件编译，或者本来需要两段代码，
|
 |
gdtvAug 11, 2017
37
我承认我这样写不规范，但需求更不规范，如果需求能保证始终如一后续不改变，我保证能写出规范的代码。
|
 |
38
不要滥用概念，，，，防御性编程是一种编程习惯，是指预见在什么地方可能会出现问题，然后创建一个环境来测试错误，当预见的问题出现的时候通知你，并执行一个你指定的损害控制动作，如停止程序执行，将用户重指向到一个备份的服务器，或者开启一个你可以用来诊断问题的调试信息。。。。
|
 |
iyaozhenAug 11, 2017 via Android
40
说实话没有见到过这样的代码，写过的、review 过的代码也有十几万行了。这样些是会被直接打回的
|
 |
weer0026Aug 11, 2017
41
强迫症表示每次都删。。
|
 |
42
是为了增加一个 block 吧，if(true) 比直接写{ }，可读性强一些。。。 就像用 do {} while(false)代替 goto
|
|
esmdxx1Aug 11, 2017 via Android
43
屏蔽我得记忆，测试什么啊
|
 |
hyyou2010Aug 11, 2017
44
比如某一段代码不需要了，但没准明天又需要了，可以这样临时处理一下。不方便注释掉，因为可能导致其他地方编译不过，一路都处理比较费劲。
|
|
esmdxx1Aug 11, 2017 via Android
45
铺天盖地得测试，你们告诉我你们是为了让我不回应，而还发铺天盖地得测试
|
 |
autoxbcAug 11, 2017
46
代码是需求的流程化描述，如果需求本身是混沌的，代码强行清晰说明丢失了信息
|
|
autoxbcAug 11, 2017
48
比如产品说，这个到底怎么弄我还没想到，你的代码要体现出这种内心的纠结
|
 |
sampengAug 11, 2017
49
原来大家 git/svn 都不怎么用的。。。为毛不直接删。如果真可能有用，打个 tag。要的时候从版本库里面找回来也就分分钟的事
|
 |
gamexgAug 11, 2017
50
如果觉得这个功能以后都不用了当然会删除 if。
但是有时候明知需求不靠谱，几天后还会改回来，就不删除 if，只修改下条件，方便下次找准地方（版本库回退是个方法，但是回退前还会有其他提交，回退不方便）。 不过如果这个功能没回退，那么 if(true) 可能就忘记导致永久留在那里了。 |
 |
kfllAug 11, 2017 via Android
52
这样就不用改缩进了呀
|
 |
elgaeAug 11, 2017
53
条件编译。没啥用，编译时优化就把 if 去掉了
|
 |
mkdongAug 11, 2017 via iPhone
54
只见过 if (false) 配合 goto
|
 |
mawenjianAug 11, 2017 via iPhone
55
控制内部变量的作用域，这样写还是有点用的。
|
 |
wzha2008Aug 11, 2017
56
if check_condition and 0:
pass if check_condition or 1: pass |
 |
boliceAug 11, 2017
57
我经常这样写，当测试环境不满足时
if(true)//(实际判断条件) { } else { } 完事正事测试时删掉 (true)// |
 |
afproAug 11, 2017 via Android
59
楼上不要瞎说 这个人明显是想干掉这个方法 直接返回 error 但是不会 aop 又不想靠 git 不敢删代码 直接写个 return 编译器又不高兴 只好用 if(true) 包起来了
|
 |
ty89Aug 11, 2017
60
预留的
这个地方很有可能将来变成由某个条件决定，因此写成 if 结构 |
 |
xiaowanggeAug 11, 2017
61
你们公司有 code review 吗？/t/291623
|
|
xiaowanggeAug 11, 2017
62
|
 |
fhefhAug 11, 2017
63
true 以前应该放了什么条件 由于某些原因又不需要了 以后可能还要 所以 就这么放着了
话说偶经常这么干~~ |
 |
flyingghostAug 11, 2017
64
@autoxbc 体现内心的纠结 233333333333
|
 |
nosugarAug 11, 2017
65
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 ”，方便，防御性开发 |
 |
linpfAug 11, 2017
66
对我来说，出现这种情况的可能性就是预留。
在短期的未来时间内，我需要在这里加个条件，但是目前还不需要。 |
 |
xuboyingAug 11, 2017 via Android
67
这是在给项目经理留台阶啊，毕竟拍脑袋的人不会理解重构，重新代码 review，从 git 历史找代码重新融合都要花时间的。
|
|
xuboyingAug 11, 2017 via Android
68
薛定谔的代码
|
 |
huluhuluAug 11, 2017
70
这种一般上
#ifdef xxxx { } #endif |
 |
jalenaAug 11, 2017
71
感觉这很正常啊！！经常条件函数没有写完的时候直接就用 true 来跑了 啊，等那边写好直接改就好了嘛！！
|
 |
superkeyAug 11, 2017
72
测试呀,我喜欢这样.
``` if(... || 1) { xxx } ``` |
 |
MatrixbirdsAug 11, 2017
73
可能是遇到了假的 true
|
 |
CruelMoonAug 11, 2017
74
调试的需要
|
 |
omygodAug 11, 2017
75
可读性高啊
|
 |
wohenyingyu01Aug 11, 2017
76
@dorentus 新的编译器应该直接不编译这个判断，这才是优化吧。
|
 |
sacubaAug 11, 2017
77
@VincentWang #20 一个需求改个十几次二十几次的，你会发现版本根本没用的！！！
|
 |
AfanyiyuAug 11, 2017
78
iftrue 应该就是 debug 用的吧，
不过要是 jit 编译的话有没有都一样， 不过，，，美观呢？ |
 |
ryd994Aug 11, 2017
79
if true
为什么不用#define ？ 孤零零一个 true，谁知道什么用 |
 |
yankebuptAug 11, 2017
83
可能是为了调试
我记得有一种上古语言 return 上不能加断点还是 return 上加断点会 bug 来的...... 如果这个是继承了那个编程习惯.... 这个 if(true)可能功能只是个行号，用来放一个断点在上面看变量内容的.... |
 |
ety001Aug 12, 2017
84
@VincentWang #20
23 楼说的很对，如果代码逻辑很复杂，你往回找好几个版本，真的是很痛苦。不如直接注释掉，写好备注信息。 |
 |
chenyu0532Aug 12, 2017
85
这没什么吧，我开发游戏的时候可能需要有一些测试的场景，我换下 true 和 false 就能直接在正式和测试的场景互换了啊。。或许有更牛逼的写法。。请赐教、、、
|
|
VincentWangAug 12, 2017
86
|
|
ety001Aug 12, 2017
87
@VincentWang #86 理想状态是这样，但是很多时候，在外包这个行业里，需求的变动快速，很可能一个改动就一个 commit 的话，会疯掉。
|
 |
ssxn58Aug 12, 2017
88
#if DO_XXXXXXX
..... #else ..... #endif |
Select Language