if(true)是个什么习惯？

不加逻辑不舒服斯基

以前需要判断 现在不需要了

注释都告诉你了。。。

多半是懒得删除 if 语句结构

我喜欢用 do{}while(0)

软删除

不是懒。是为了防止以后又要改回去

难道是被产品逼的？

业务写多了， 你如果看到这种代码，也见惯不怪了。

boolean flag = check(model); //检查模型部分参数及功能合法性

flag = true; //由于 XXX 需求修改

if(flag == true){
//do something
}else{
//do other
}

我也喜欢这样，不过吃过不少亏
记得旁边加个注释，// FIXME

这叫防御性开发，防止需求的多次更改

@play78 #8
你这样改问题很大。。。。。。不应该继续执行 check 方法了。

boolean flag = true; //check(model); //检查模型部分参数及功能合法性 // 20170811 由于 XXX 需求修改

我一般会这样改。保持原来的代码在，但注释掉，不要再执行。你懂的万一需求脑抽又要改回去，不能删掉 check 的代码

好像在哪见过，/t/375091

开关要么是配置,要么常量. 直接这么写也就 DEBUG 的时候.发版的时候还有这种就不太专业.

我喜欢用注释

//* 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');
//*/

防御性开发，他是一个老司机，你要跟他学习

很早以前看过的一篇文章
http://www.bitnative.com/2012/10/22/kill-the-zombies-in-your-code/
一直记得他的核心观点：不用就删，别不舍得
“说不准哪天会用到”的东西，十有八九是再也用不到了，或者很久很久才会用到。而这些注释代码对于后续开发是一种干扰，尤其是交给其他人时。
真要保留 A/B 两种方案时，可以尝试分别封装到模块或者函数里，代码干净很多。

如果是开发过程中临时 mock，我一般会加上注释
// TODO 调试用，上线前删掉

调试到不用调试了。

那些说需求来回改的，你们代码不用版本控制吗？ 老代码在版本里，不要的代码就删了啊...

好奇怎么通过 code review 的 还什么防御性开发 牛逼

@littleylv #12 然而发现 Check 是个有副作用的函数 卒

@VincentWang 版本控制如果改动多的话时间一长几十个版本去找浪费时间，而且代码逻辑复杂的情况下更麻烦，上面说的，写 fixme+注释比较妥当

我们也经常这样 ，有时候需要 临时关闭 某个功能，我的经验是 老代码写成这样 往往都是有原因的。

骗编译器？
比如
```
if(true) return xxx;
// other codes
...
```

@VincentWang +1

很多新手都有这个问题，代码舍不得删，各种大段注释。我说从版本库里找回来不就行了，他们说太麻烦。。。
其实就是懒。

话说，那么多注释的代码看着不累么。。。

@littleylv 这样做是过不了代码覆盖率检查的。

如果不加 if，return 下面如果有代码，有些 ide 会报错

代码少还好，多了看得是比较烦人的。

防御性开发最多做个为空判断 ,其他代码都删掉吧 ,基本上用不到.

上面说 code review、版本控制的，纯粹是你们的需求改的不够多罢了。
当然，我承认这样写不好。

还什么防御性开发，代码不规范就是不规范，懒就是懒。
所谓的为了防止需求变动，你就那 2 行代码改起来都觉得费事吗？
而且对于经常变动的业务，也不应该写这种硬编码的代码，更应该考虑把相关逻辑转移到配置文件或者数据库中，这才是"防御性开发"。

@miniwade514 为什么要立这样的 flag ……

if (ENV_IS_NOT_PRODUCTION) {
//do sth. dirty
}

@Mutoo 碰巧我也是…

当注释用吧，，，

楼主你用你得先夺为主得偏见，首先就确定事情得结构，事实上得情况 ，复杂很多，所以原因也太多，比如，自己定义得条件编译，或者本来需要两段代码，

我承认我这样写不规范，但需求更不规范，如果需求能保证始终如一后续不改变，我保证能写出规范的代码。

不要滥用概念，，，，防御性编程是一种编程习惯，是指预见在什么地方可能会出现问题，然后创建一个环境来测试错误，当预见的问题出现的时候通知你，并执行一个你指定的损害控制动作，如停止程序执行，将用户重指向到一个备份的服务器，或者开启一个你可以用来诊断问题的调试信息。。。。

@fan123199 不过即使加了，比较新的编译器也还是会报错或者警告……

说实话没有见到过这样的代码，写过的、review 过的代码也有十几万行了。这样些是会被直接打回的

强迫症表示每次都删。。

是为了增加一个 block 吧，if(true) 比直接写{ }，可读性强一些。。。 就像用 do {} while(false)代替 goto

屏蔽我得记忆，测试什么啊

比如某一段代码不需要了，但没准明天又需要了，可以这样临时处理一下。不方便注释掉，因为可能导致其他地方编译不过，一路都处理比较费劲。

铺天盖地得测试，你们告诉我你们是为了让我不回应，而还发铺天盖地得测试

代码是需求的流程化描述，如果需求本身是混沌的，代码强行清晰说明丢失了信息

@nicevar 不能很快找到大概说明了 commit message 写的不清楚吧

比如产品说，这个到底怎么弄我还没想到，你的代码要体现出这种内心的纠结

原来大家 git/svn 都不怎么用的。。。为毛不直接删。如果真可能有用，打个 tag。要的时候从版本库里面找回来也就分分钟的事

如果觉得这个功能以后都不用了当然会删除 if。
但是有时候明知需求不靠谱，几天后还会改回来，就不删除 if，只修改下条件，方便下次找准地方（版本库回退是个方法，但是回退前还会有其他提交，回退不方便）。

不过如果这个功能没回退，那么 if(true) 可能就忘记导致永久留在那里了。

@littleylv

build error: unused function 'check'

这样就不用改缩进了呀

条件编译。没啥用，编译时优化就把 if 去掉了

只见过 if (false) 配合 goto

控制内部变量的作用域，这样写还是有点用的。

if check_condition and 0:
pass

if check_condition or 1:
pass

我经常这样写，当测试环境不满足时
if(true)//(实际判断条件)
{
}
else
{
}
完事正事测试时删掉 (true)//

@mawenjian #55 内部变量的作用域，直接加个大括号就够了，仅针对 c。

楼上不要瞎说 这个人明显是想干掉这个方法 直接返回 error 但是不会 aop 又不想靠 git 不敢删代码 直接写个 return 编译器又不高兴 只好用 if(true) 包起来了

预留的

这个地方很有可能将来变成由某个条件决定，因此写成 if 结构

你们公司有 code review 吗？/t/291623

你们公司有 code review 吗？

/t/291623

t/291623

true 以前应该放了什么条件 由于某些原因又不需要了 以后可能还要 所以 就这么放着了

话说偶经常这么干~~

@autoxbc 体现内心的纠结 233333333333

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 ”，方便，防御性开发

对我来说，出现这种情况的可能性就是预留。
在短期的未来时间内，我需要在这里加个条件，但是目前还不需要。

这是在给项目经理留台阶啊，毕竟拍脑袋的人不会理解重构，重新代码 review，从 git 历史找代码重新融合都要花时间的。

薛定谔的代码

@play78 if(flag == true) ???

这种一般上
#ifdef xxxx
{
}
#endif

感觉这很正常啊！！经常条件函数没有写完的时候直接就用 true 来跑了 啊，等那边写好直接改就好了嘛！！

测试呀,我喜欢这样.
```
if(... || 1) {
xxx
}
```

可能是遇到了假的 true

调试的需要

可读性高啊

@dorentus 新的编译器应该直接不编译这个判断，这才是优化吧。

@VincentWang #20 一个需求改个十几次二十几次的，你会发现版本根本没用的！！！

iftrue 应该就是 debug 用的吧，
不过要是 jit 编译的话有没有都一样，
不过，，，美观呢？

if true
为什么不用#define ？
孤零零一个 true，谁知道什么用

@fan123199 然而，如果那里需要有一个无条件的 return，它下面本来就应该是没有代码的呀……

@DrJoseph hahahah

@DrJoseph 防御性开发，好词

可能是为了调试
我记得有一种上古语言 return 上不能加断点还是 return 上加断点会 bug 来的......
如果这个是继承了那个编程习惯....
这个 if(true)可能功能只是个行号，用来放一个断点在上面看变量内容的....

@VincentWang #20
23 楼说的很对，如果代码逻辑很复杂，你往回找好几个版本，真的是很痛苦。不如直接注释掉，写好备注信息。

这没什么吧，我开发游戏的时候可能需要有一些测试的场景，我换下 true 和 false 就能直接在正式和测试的场景互换了啊。。或许有更牛逼的写法。。请赐教、、、

@nicevar @sacuba @ety001 嗯，你们说的也有道理。如果 commit 的颗粒度和 message 做好了其实也不麻烦，一个 commit 解决一个问题，同时把 commit message 写好，找回的时候看 commit log。

@VincentWang #86 理想状态是这样，但是很多时候，在外包这个行业里，需求的变动快速，很可能一个改动就一个 commit 的话，会疯掉。

#if DO_XXXXXXX
.....
#else
.....
#endif