代码洁癖症的表现

有下列情形之一的，你患上了代码洁癖症。症状程度可轻可重，轻者帮助写出优雅整洁的代码，重者走火入魔，万劫不复。

1. 多余的空行、分号，没有使用的变量，见一个删一个。
2. tab或者空格没有对齐的必须纠正过来，除了缩进用，不允许看到代码内连续两个空格。
3. 看到一个类某个方法没有注释，不由自主地加上，不管有没有意义。
4. 错误的拼写，无论是在命名还是注释必须纠正过来；不一致的大小写，必须要纠正过来；标点符号的遗漏，必须补上。
5. 看到if(a==0)这样的代码必须改成if(0==a)这样的形式。
6. 所有IDE对代码的告警必须消除，无论采取的方式是否有实际意义。
7. 看到赤裸的数字，必须定义成常量，即便数字表意很直观，还是只能接受常量数字。
8. 见不得非静态的公有变量，必须建立get/set方法。
9. 不断地按代码格式整理的快捷键，在Eclipse就是不断地CTRL+Shift+F、CTRL+Shift+O，甚至不住地CTRL+S。
10. 一旦看到超过连续3个的if-else判断分支，就要优化；类似的方法调用代码，如果连续出现，就要优化；超过若干行的方法，必须重构。
11. 最本质的表现，喜欢长时间阅读自己的代码，心中一边啧啧赞赏不已，一边自我陶醉。

文章系本人原创，转载请保持完整性并注明出自《四火的唠叨》

评论

69 楼 liukai 2013-02-25  

liukai 写道

    function (parameter) {  
       boolean result = false;

        if( condition == true) {  
      
            //省略若干行代码  
           result  = true ;  
      
        }  
      
        //省略若干行代码  
        return result

标记器不好用啊

68 楼 liukai 2013-02-25  

    function (parameter) {  
       boolean result = false;

        if( condition == true) {  
      
            //省略若干行代码  
           result  = true ;  
      
        }  
      
        //省略若干行代码  

67 楼 liukai 2013-02-25  

songgz 写道

lg_asus 写道

Nightlee 写道

witcheryne 写道

中了不少抢...

多层 if 嵌套也会受不了.
想都不想就用 if-else 也受不了.

function (parameter) {

    if( condition == true) {

        //省略若干行代码
        return a;

    } else {

        //省略若干行代码
        return b;
    }

}

我就特么的想改成:

function (parameter) {

    if( condition == true) {

        //省略若干行代码
        return a;

    }

    //省略若干行代码
    return b;

}

这个写法其实有弊端，代码中间的return相当于变相的goto，破坏了代码的顺序，还是喜欢if-else里面赋值最后再return

这种写法叫做guard clause

function (parameter) {

    if( condition == true) {

        //省略若干行代码
        return a;

    }

    //省略若干行代码
    return b;

}

这个写法是效率最高的，只有了解计算机体系结构的大师，才深谙此道，经常如此用。

代码的好坏，不仅仅是形式和逻辑上的。

function (parameter) { if( condition == true) { //省略若干行代码 return a; } //省略若干行代码 return b; }

66 楼 anhui3713 2013-02-25  

kidneyball 写道

youarestupid 写道

RayChase 写道

kidneyball 写道

runfriends 写道

我一直想知道过多的if-else怎么优化。有很多时候只能使用if-else做判断

如果每个分支做的事情很简单且分支不大可能增加可以改为switch。如果每个分支做的事情比较多，或者将来有可能增加分支可以改为责任链模式。

评论里说的对于过多if else优化的方式都不对，至少是很片面的，我去写一篇怎么重构过多if else的文章。

应该是策略模式。

对于替代单一位置的复杂if分支，策略模式只能替代单选分支的情况（如果一个客户类会持有一串策略类实例依次调用，就变成责任链了），责任链则可以通吃。每个匹配的责任链结点处理后不向后传递控制，可替代if...else if...else if...的情况。处理后继续传递控制，则可替代if...; if...; if...;的情况。每个结点还有机会改变或封装传入参数，影响后续的结点。而且每个结点可以拆出来单独使用，或者重新组合。对于替代内部的分支结构，个人感觉更为灵活。

策略模式的强项是处理同一分支结构在多处反复出现的情况（责任链其实也能用于这种情况，但太过抽象，无法向实现者传递设计意图）。在设计框架性的API时，策略模式能限定实现者必须实现的接口，和通过接口向实现者传递一些设计意图。

很多if问题如果是判断我也不太喜欢用switch,个人喜欢把每个逻辑代码封装起来然后通过map实现key-value的映射然后来调用对应的代码执行...基本上省去了判断的过程...虽然效率低很多..但是代码简洁不少

65 楼 jazzmozart 2013-02-25  

jazzmozart 写道

哈哈，第14条还真是走火入魔了

11条

64 楼 jazzmozart 2013-02-25  

哈哈，第14条还真是走火入魔了

63 楼 yanmingeye 2013-02-25  

  我很多缺点都有

62 楼 songgz 2013-02-25  

lg_asus 写道

Nightlee 写道

witcheryne 写道

中了不少抢...

多层 if 嵌套也会受不了.
想都不想就用 if-else 也受不了.

function (parameter) {

    if( condition == true) {

        //省略若干行代码
        return a;

    } else {

        //省略若干行代码
        return b;
    }

}

我就特么的想改成:

function (parameter) {

    if( condition == true) {

        //省略若干行代码
        return a;

    }

    //省略若干行代码
    return b;

}

这个写法其实有弊端，代码中间的return相当于变相的goto，破坏了代码的顺序，还是喜欢if-else里面赋值最后再return

这种写法叫做guard clause

function (parameter) {

    if( condition == true) {

        //省略若干行代码
        return a;

    }

    //省略若干行代码
    return b;

}

这个写法是效率最高的，只有了解计算机体系结构的大师，才深谙此道，经常如此用。
代码的好坏，不仅仅是形式和逻辑上的。

61 楼 zoven 2013-02-25  

中了大部分

60 楼 zhoujiangjohn 2013-02-25  

rox 写道

搞IT的，多半都会有些强迫症。

本人就有点。

59 楼 programmer 2013-02-25  

悲剧，好像说的是我

58 楼 小鑫。 2013-02-25  

躺枪，重度洁癖，外加强迫症。

57 楼 lake85520 2013-02-25  

同样的事情，有人认为是洁癖，也有人会认为是细节，见仁见智吧。上面的那些现象，曾经或者现在都一直保持着，哈哈。只要有空余的时间，总喜欢重构代码，提升效率。有些时候算一种自我陶醉，更多时候是为了避免麻烦呵。写一手漂亮的代码最起码好过写一手糟糕的代码，不仅自己看着舒服，修改起来方便，也能给别人一种舒心的感觉，最起码不反感。让人乐意去看你的代码，才有心情去修改。相当反感下班或者休假的时候接到工作上的电话，所以写有“洁癖”的代码也算给自己免除不必要的麻烦吧，呵呵。工作中付出的多一点，生活中就享受多一点。

56 楼 thierry.xing 2013-02-25  

全部中枪

55 楼 cometlj 2013-02-25  

顶你一个 代码洁癖症

54 楼 kidneyball 2013-02-25  

kidneyball 写道

此外，策略模式只适用于条件可以提前到注入阶段进行判断，注入后与条件有关的状态不再发生变动的情况。如果你的if分支依赖于一个运行期经常改变的量，那你在每次调用策略前都要根据同样的一组if判断去创建相应的策略实例，那就是多此一举了。事实上有不少应用在创建策略实例的工厂里还是用了责任链，换句话说，策略模式的作用是把多个相同的分支结构统一为一个，并且提前到注入期进行一次性判断。而责任链则实际取代了这个分支结构。

再絮叨絮叨，Java里使用策略模式取代分支一种常见的做法是enum上挂一个策略实例。同样只能用于单分支场景。这种做法本质上是把策略挂到数据（不一定是enum）上，只能用于一个数据恰好对应一种策略的情况，不能满足复杂的条件判断（否则把条件对应到数据又是一堆if）。但如果刚好能满足实际需求的话，倒是一种很直观的做法。

53 楼 silence945 2013-02-25  

全中枪了。。。

52 楼 kidneyball 2013-02-25  

youarestupid 写道

RayChase 写道

kidneyball 写道

runfriends 写道

我一直想知道过多的if-else怎么优化。有很多时候只能使用if-else做判断

如果每个分支做的事情很简单且分支不大可能增加可以改为switch。如果每个分支做的事情比较多，或者将来有可能增加分支可以改为责任链模式。

评论里说的对于过多if else优化的方式都不对，至少是很片面的，我去写一篇怎么重构过多if else的文章。

应该是策略模式。

此外，策略模式只适用于条件可以提前到注入阶段进行判断，注入后与条件有关的状态不再发生变动的情况。如果你的if分支依赖于一个运行期经常改变的量，那你在每次调用策略前都要根据同样的一组if判断去创建相应的策略实例，那就是多此一举了。事实上有不少应用在创建策略实例的工厂里还是用了责任链，换句话说，策略模式的作用是把多个相同的分支结构统一为一个，并且提前到注入期进行一次性判断。而责任链则实际取代了这个分支结构。

51 楼 kidneyball 2013-02-25  

youarestupid 写道

RayChase 写道

kidneyball 写道

runfriends 写道

我一直想知道过多的if-else怎么优化。有很多时候只能使用if-else做判断

如果每个分支做的事情很简单且分支不大可能增加可以改为switch。如果每个分支做的事情比较多，或者将来有可能增加分支可以改为责任链模式。

评论里说的对于过多if else优化的方式都不对，至少是很片面的，我去写一篇怎么重构过多if else的文章。

应该是策略模式。

对于替代单一位置的复杂if分支，策略模式只能替代单选分支的情况（如果一个客户类会持有一串策略类实例依次调用，就变成责任链了），责任链则可以通吃。每个匹配的责任链结点处理后不向后传递控制，可替代if...else if...else if...的情况。处理后继续传递控制，则可替代if...; if...; if...;的情况。每个结点还有机会改变或封装传入参数，影响后续的结点。而且每个结点可以拆出来单独使用，或者重新组合。对于替代内部的分支结构，个人感觉更为灵活。

策略模式的强项是处理同一分支结构在多处反复出现的情况（责任链其实也能用于这种情况，但太过抽象，无法向实现者传递设计意图）。在设计框架性的API时，策略模式能限定实现者必须实现的接口，和通过接口向实现者传递一些设计意图。

50 楼 sanshizi 2013-02-25  

支持代码洁癖症