V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
retanoj
V2EX  ›  程序员

if(true)是个什么习惯?

  •  
  •   retanoj · 2017-08-11 09:02:29 +08:00 · 13361 次点击
    这是一个创建于 2421 天前的主题,其中的信息可能已经有所发展或是发生改变。

    经常在代码里看到这种用法

    // 关闭某个接口

    if(true) { return APIResultVo.error(xxxx); }

    这个 if( true ) 是什么编程习惯?有什么说法么?

    88 条回复    2017-08-12 15:55:32 +08:00
    gigantic222
        1
    gigantic222  
       2017-08-11 09:03:44 +08:00 via iPhone
    不加逻辑不舒服斯基
    ericls
        2
    ericls  
       2017-08-11 09:03:48 +08:00 via iPhone
    以前需要判断 现在不需要了
    blankme
        3
    blankme  
       2017-08-11 09:05:22 +08:00
    注释都告诉你了。。。
    Rice
        4
    Rice  
       2017-08-11 09:05:31 +08:00
    多半是懒得删除 if 语句结构
    veelog
        5
    veelog  
       2017-08-11 09:06:34 +08:00 via iPhone
    我喜欢用 do{}while(0)
    facetest
        6
    facetest  
       2017-08-11 09:06:43 +08:00 via Android
    软删除
    littleylv
        7
    littleylv  
       2017-08-11 09:07:20 +08:00   ❤️ 24
    不是懒。是为了防止以后又要改回去
    syncher
        8
    syncher  
       2017-08-11 09:09:45 +08:00 via Android
    难道是被产品逼的?
    play78
        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
    }
    congeec
        10
    congeec  
       2017-08-11 09:15:15 +08:00
    我也喜欢这样,不过吃过不少亏
    记得旁边加个注释,// FIXME
    DrJoseph
        11
    DrJoseph  
       2017-08-11 09:16:18 +08:00   ❤️ 9
    这叫防御性开发,防止需求的多次更改
    littleylv
        12
    littleylv  
       2017-08-11 09:16:43 +08:00
    @play78 #8
    你这样改问题很大。。。。。。不应该继续执行 check 方法了。

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

    我一般会这样改。保持原来的代码在,但注释掉,不要再执行。你懂的万一需求脑抽又要改回去,不能删掉 check 的代码
    LeoNG
        13
    LeoNG  
       2017-08-11 09:21:05 +08:00
    好像在哪见过,/t/375091
    ThatIsFine
        14
    ThatIsFine  
       2017-08-11 09:21:09 +08:00
    开关要么是配置,要么常量. 直接这么写也就 DEBUG 的时候.发版的时候还有这种就不太专业.
    Mutoo
        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');
    //*/
    SourceMan
        16
    SourceMan  
       2017-08-11 09:27:36 +08:00   ❤️ 2
    防御性开发,他是一个老司机,你要跟他学习
    miniwade514
        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 两种方案时,可以尝试分别封装到模块或者函数里,代码干净很多。
    miniwade514
        18
    miniwade514  
       2017-08-11 09:31:42 +08:00
    如果是开发过程中临时 mock,我一般会加上注释
    // TODO 调试用,上线前删掉
    raiz
        19
    raiz  
       2017-08-11 09:32:08 +08:00
    调试到不用调试了。
    VincentWang
        20
    VincentWang  
       2017-08-11 09:32:30 +08:00   ❤️ 1
    那些说需求来回改的,你们代码不用版本控制吗? 老代码在版本里,不要的代码就删了啊...
    Perry
        21
    Perry  
       2017-08-11 09:35:37 +08:00 via iPhone
    好奇怎么通过 code review 的 还什么防御性开发 牛逼
    Monad
        22
    Monad  
       2017-08-11 09:39:04 +08:00
    @littleylv #12 然而发现 Check 是个有副作用的函数 卒
    nicevar
        23
    nicevar  
       2017-08-11 09:44:34 +08:00
    @VincentWang 版本控制如果改动多的话时间一长几十个版本去找浪费时间,而且代码逻辑复杂的情况下更麻烦,上面说的,写 fixme+注释比较妥当
    hiboshi
        24
    hiboshi  
       2017-08-11 09:46:06 +08:00
    我们也经常这样 ,有时候需要 临时关闭 某个功能,我的经验是 老代码写成这样 往往都是有原因的。
    shard
        25
    shard  
       2017-08-11 09:49:58 +08:00
    骗编译器?
    比如
    ```
    if(true) return xxx;
    // other codes
    ...
    ```
    Lucups
        26
    Lucups  
       2017-08-11 09:50:41 +08:00   ❤️ 5
    @VincentWang +1

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

    话说,那么多注释的代码看着不累么。。。
    stephen9357
        27
    stephen9357  
       2017-08-11 10:13:34 +08:00
    @littleylv 这样做是过不了代码覆盖率检查的。
    fan123199
        28
    fan123199  
       2017-08-11 10:29:18 +08:00
    如果不加 if,return 下面如果有代码,有些 ide 会报错
    bk201
        29
    bk201  
       2017-08-11 10:40:01 +08:00
    代码少还好,多了看得是比较烦人的。
    loveCoding
        30
    loveCoding  
       2017-08-11 10:43:30 +08:00
    防御性开发最多做个为空判断 ,其他代码都删掉吧 ,基本上用不到.
    ma125125t
        31
    ma125125t  
       2017-08-11 10:45:29 +08:00
    上面说 code review、版本控制的,纯粹是你们的需求改的不够多罢了。
    当然,我承认这样写不好。
    jason2017
        32
    jason2017  
       2017-08-11 10:50:04 +08:00
    还什么防御性开发,代码不规范就是不规范,懒就是懒。
    所谓的为了防止需求变动,你就那 2 行代码改起来都觉得费事吗?
    而且对于经常变动的业务,也不应该写这种硬编码的代码,更应该考虑把相关逻辑转移到配置文件或者数据库中,这才是"防御性开发"。
    mcfog
        33
    mcfog  
       2017-08-11 10:50:39 +08:00
    @miniwade514 为什么要立这样的 flag ……

    if (ENV_IS_NOT_PRODUCTION) {
    //do sth. dirty
    }
    am241
        34
    am241  
       2017-08-11 10:53:24 +08:00 via Android
    @Mutoo 碰巧我也是…
    pynix
        35
    pynix  
       2017-08-11 10:55:24 +08:00
    当注释用吧,,,
    esmdxx1
        36
    esmdxx1  
       2017-08-11 11:04:13 +08:00 via Android
    楼主你用你得先夺为主得偏见,首先就确定事情得结构,事实上得情况 ,复杂很多,所以原因也太多,比如,自己定义得条件编译,或者本来需要两段代码,
    gdtv
        37
    gdtv  
       2017-08-11 11:05:15 +08:00
    我承认我这样写不规范,但需求更不规范,如果需求能保证始终如一后续不改变,我保证能写出规范的代码。
    flowci
        38
    flowci  
       2017-08-11 11:15:00 +08:00   ❤️ 3
    不要滥用概念,,,,防御性编程是一种编程习惯,是指预见在什么地方可能会出现问题,然后创建一个环境来测试错误,当预见的问题出现的时候通知你,并执行一个你指定的损害控制动作,如停止程序执行,将用户重指向到一个备份的服务器,或者开启一个你可以用来诊断问题的调试信息。。。。
    dorentus
        39
    dorentus  
       2017-08-11 11:17:47 +08:00
    @fan123199 不过即使加了,比较新的编译器也还是会报错或者警告……
    iyaozhen
        40
    iyaozhen  
       2017-08-11 11:20:29 +08:00 via Android
    说实话没有见到过这样的代码,写过的、review 过的代码也有十几万行了。这样些是会被直接打回的
    weer0026
        41
    weer0026  
       2017-08-11 11:21:20 +08:00
    强迫症表示每次都删。。
    broker
        42
    broker  
       2017-08-11 11:30:16 +08:00   ❤️ 1
    是为了增加一个 block 吧,if(true) 比直接写{ },可读性强一些。。。 就像用 do {} while(false)代替 goto
    esmdxx1
        43
    esmdxx1  
       2017-08-11 11:30:25 +08:00 via Android
    屏蔽我得记忆,测试什么啊
    hyyou2010
        44
    hyyou2010  
       2017-08-11 11:30:39 +08:00
    比如某一段代码不需要了,但没准明天又需要了,可以这样临时处理一下。不方便注释掉,因为可能导致其他地方编译不过,一路都处理比较费劲。
    esmdxx1
        45
    esmdxx1  
       2017-08-11 11:33:04 +08:00 via Android
    铺天盖地得测试,你们告诉我你们是为了让我不回应,而还发铺天盖地得测试
    autoxbc
        46
    autoxbc  
       2017-08-11 11:52:11 +08:00
    代码是需求的流程化描述,如果需求本身是混沌的,代码强行清晰说明丢失了信息
    langxuan
        47
    langxuan  
       2017-08-11 11:55:07 +08:00
    @nicevar 不能很快找到大概说明了 commit message 写的不清楚吧
    autoxbc
        48
    autoxbc  
       2017-08-11 11:56:03 +08:00
    比如产品说,这个到底怎么弄我还没想到,你的代码要体现出这种内心的纠结
    sampeng
        49
    sampeng  
       2017-08-11 12:04:40 +08:00
    原来大家 git/svn 都不怎么用的。。。为毛不直接删。如果真可能有用,打个 tag。要的时候从版本库里面找回来也就分分钟的事
    gamexg
        50
    gamexg  
       2017-08-11 12:04:42 +08:00
    如果觉得这个功能以后都不用了当然会删除 if。
    但是有时候明知需求不靠谱,几天后还会改回来,就不删除 if,只修改下条件,方便下次找准地方(版本库回退是个方法,但是回退前还会有其他提交,回退不方便)。

    不过如果这个功能没回退,那么 if(true) 可能就忘记导致永久留在那里了。
    miyuki
        51
    miyuki  
       2017-08-11 12:29:03 +08:00
    @littleylv

    build error: unused function 'check'
    kfll
        52
    kfll  
       2017-08-11 12:37:04 +08:00 via Android
    这样就不用改缩进了呀
    elgae
        53
    elgae  
       2017-08-11 12:38:59 +08:00
    条件编译。没啥用,编译时优化就把 if 去掉了
    mkdong
        54
    mkdong  
       2017-08-11 12:44:26 +08:00 via iPhone
    只见过 if (false) 配合 goto
    mawenjian
        55
    mawenjian  
       2017-08-11 12:56:27 +08:00 via iPhone
    控制内部变量的作用域,这样写还是有点用的。
    wzha2008
        56
    wzha2008  
       2017-08-11 12:58:50 +08:00
    if check_condition and 0:
    pass

    if check_condition or 1:
    pass
    bolice
        57
    bolice  
       2017-08-11 13:39:25 +08:00
    我经常这样写,当测试环境不满足时
    if(true)//(实际判断条件)
    {
    }
    else
    {
    }
    完事正事测试时删掉 (true)//
    bolice
        58
    bolice  
       2017-08-11 13:40:16 +08:00
    @mawenjian #55 内部变量的作用域,直接加个大括号就够了,仅针对 c。
    afpro
        59
    afpro  
       2017-08-11 13:54:30 +08:00 via Android
    楼上不要瞎说 这个人明显是想干掉这个方法 直接返回 error 但是不会 aop 又不想靠 git 不敢删代码 直接写个 return 编译器又不高兴 只好用 if(true) 包起来了
    ty89
        60
    ty89  
       2017-08-11 14:35:21 +08:00
    预留的

    这个地方很有可能将来变成由某个条件决定,因此写成 if 结构
    xiaowangge
        61
    xiaowangge  
       2017-08-11 14:36:29 +08:00
    你们公司有 code review 吗?/t/291623
    xiaowangge
        62
    xiaowangge  
       2017-08-11 14:36:58 +08:00
    你们公司有 code review 吗?

    /t/291623

    t/291623
    fhefh
        63
    fhefh  
       2017-08-11 15:03:19 +08:00
    true 以前应该放了什么条件 由于某些原因又不需要了 以后可能还要 所以 就这么放着了

    话说偶经常这么干~~
    flyingghost
        64
    flyingghost  
       2017-08-11 15:48:43 +08:00
    @autoxbc 体现内心的纠结 233333333333
    nosugar
        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 ”,方便,防御性开发
    linpf
        66
    linpf  
       2017-08-11 16:29:27 +08:00
    对我来说,出现这种情况的可能性就是预留。
    在短期的未来时间内,我需要在这里加个条件,但是目前还不需要。
    xuboying
        67
    xuboying  
       2017-08-11 16:43:53 +08:00 via Android
    这是在给项目经理留台阶啊,毕竟拍脑袋的人不会理解重构,重新代码 review,从 git 历史找代码重新融合都要花时间的。
    xuboying
        68
    xuboying  
       2017-08-11 16:44:52 +08:00 via Android
    薛定谔的代码
    cwek
        69
    cwek  
       2017-08-11 16:56:47 +08:00
    @play78 if(flag == true) ???
    huluhulu
        70
    huluhulu  
       2017-08-11 17:37:51 +08:00
    这种一般上
    #ifdef xxxx
    {
    }
    #endif
    jalena
        71
    jalena  
       2017-08-11 17:39:47 +08:00
    感觉这很正常啊!!经常条件函数没有写完的时候直接就用 true 来跑了 啊,等那边写好直接改就好了嘛!!
    superkey
        72
    superkey  
       2017-08-11 17:58:25 +08:00
    测试呀,我喜欢这样.
    ```
    if(... || 1) {
    xxx
    }
    ```
    Matrixbirds
        73
    Matrixbirds  
       2017-08-11 18:30:04 +08:00
    可能是遇到了假的 true
    CruelMoon
        74
    CruelMoon  
       2017-08-11 18:31:56 +08:00
    调试的需要
    omygod
        75
    omygod  
       2017-08-11 18:41:21 +08:00
    可读性高啊
    wohenyingyu01
        76
    wohenyingyu01  
       2017-08-11 19:13:53 +08:00
    @dorentus 新的编译器应该直接不编译这个判断,这才是优化吧。
    sacuba
        77
    sacuba  
       2017-08-11 19:17:58 +08:00
    @VincentWang #20 一个需求改个十几次二十几次的,你会发现版本根本没用的!!!
    Afanyiyu
        78
    Afanyiyu  
       2017-08-11 19:24:44 +08:00
    iftrue 应该就是 debug 用的吧,
    不过要是 jit 编译的话有没有都一样,
    不过,,,美观呢?
    ryd994
        79
    ryd994  
       2017-08-11 20:59:47 +08:00
    if true
    为什么不用#define ?
    孤零零一个 true,谁知道什么用
    metorm
        80
    metorm  
       2017-08-11 21:20:15 +08:00
    @fan123199 然而,如果那里需要有一个无条件的 return,它下面本来就应该是没有代码的呀……
    imswing
        81
    imswing  
       2017-08-11 21:28:30 +08:00 via Android
    @DrJoseph hahahah
    kevinzhwl
        82
    kevinzhwl  
       2017-08-11 22:13:57 +08:00
    @DrJoseph 防御性开发,好词
    yankebupt
        83
    yankebupt  
       2017-08-11 23:23:35 +08:00
    可能是为了调试
    我记得有一种上古语言 return 上不能加断点还是 return 上加断点会 bug 来的......
    如果这个是继承了那个编程习惯....
    这个 if(true)可能功能只是个行号,用来放一个断点在上面看变量内容的....
    ety001
        84
    ety001  
       2017-08-12 00:33:48 +08:00
    @VincentWang #20
    23 楼说的很对,如果代码逻辑很复杂,你往回找好几个版本,真的是很痛苦。不如直接注释掉,写好备注信息。
    chenyu0532
        85
    chenyu0532  
       2017-08-12 09:26:45 +08:00
    这没什么吧,我开发游戏的时候可能需要有一些测试的场景,我换下 true 和 false 就能直接在正式和测试的场景互换了啊。。或许有更牛逼的写法。。请赐教、、、
    VincentWang
        86
    VincentWang  
       2017-08-12 11:31:26 +08:00
    @nicevar @sacuba @ety001 嗯,你们说的也有道理。如果 commit 的颗粒度和 message 做好了其实也不麻烦,一个 commit 解决一个问题,同时把 commit message 写好,找回的时候看 commit log。
    ety001
        87
    ety001  
       2017-08-12 13:16:17 +08:00
    @VincentWang #86 理想状态是这样,但是很多时候,在外包这个行业里,需求的变动快速,很可能一个改动就一个 commit 的话,会疯掉。
    ssxn58
        88
    ssxn58  
       2017-08-12 15:55:32 +08:00
    #if DO_XXXXXXX
    .....
    #else
    .....
    #endif
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3319 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 11:25 · PVG 19:25 · LAX 04:25 · JFK 07:25
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.