不要 if else 的编程

不用if else，难道用switch？

每个语言都不同，不能一概而论

很多 Design Pattern 的手法就是把 if-else 成多。

我都干过把 if-else 换成反射来着。。。

if-else的性能还是非常好的，那些提到的替代算法：仅仅是为了浪费CPU而做的轮子。同时，那些算法的可读性，其实并不像他们想象的那样有提高，我认为是“下降”了。

if else 简洁高效

但是很方便写上N层, 不用考虑梳理业务, 导致代码无法维护, 这才是被诟病的原因. 说到底是程序员自己的问题. 代价太低, 啥水平的人都能上来添乱

把所有程序员偷懒的路子都堵上, 不见得是好事.

奥卡姆剃刀

就知道他要说用多态或者表带替代switch和if/else.

多态，NullObject 都是消除 if-else 的方法，可以让结构看起来清晰一些。

在《程序员的数学》里面有个例子，有个人要吃一个月的药，规则是单日吃，双日不吃，但是他经常记不起来今天是单日还是双日，所以它就弄了30个药丸，其中15个有药剂，15个空的，间隔排开，然后每天都吃一个，这样它就不用管（if-else）今天是单日还是双日了。

恩，有些地方确实一点也没用if-else，真的，都是JC,JNC,CJNE,DJNZ。。。

有分支就有if
else的地方都能用return

里面的例子完全不适用，他那个能拆开是因为代码本身就该将take和padding解耦

@Mutoo 再加一个table drive

设计模式是毒药，已经毒到每写一个函数都考虑要不要建一个类。
后来我领悟了，第一次写代码，除非认定到后期一定会变化，否则直接写，等到以后变的时候再搞。
实现功能是主要，if else 就算你用拼音命名也不是不可以，只要你身边都能看懂，一切都ok。

为什么不用、 if else 描述分支再好不过了

《不要过度设计》

凡事一概而论多半完蛋

为了这，还不如去写函数式。

避免不了， 但可以尽量少用。

看到标题第一反应是楼主要介绍haskell了么

准确的说法应该是不要滥用if else编程，

if else的层次越多，越接近goto语句，可读性越差。复杂的if else可以重构改善可读性。文章里的例子不算好，简单的if else对程序员来说是很容易读懂，没必要折腾。

呵呵。。。

这个装逼不算。有本事写汇编不要用CMP

其实你们可以用这种方式代替branching：
([lambda_t, lambda_f][to_int (not cond_expr)])();

其中lambda_t是true分支，当cond_expr求值为true时，to_int(not true)为0所以调用lambda_t；反之调用lambda_f。当然原文的本意也不是鼓励我们这么矫枉过正地回避branching。

用语言特性和设计模式代替条件选择么？

@Golevka 就是表驱动么?一个函指针数组,具体取下标由执行一个判断函数来确定,但是很多强类型语言里面要求列表中放置同类型数据,所以要lambda_t,lambda_f有相同的函数签名(例如csharp
int a = 0;
Func<int> getIndex = ()=>{return 1;};
new List<Action> { () => { a = 10; }, () => { a = 20; } }[getIndex()]();)
.....就算可以再外面包上一层相同原型的函数....效率不是更低了么毕竟多了几次call呢.....而且这样表驱动的话.....本身就是找列表地址然后call.....对比cmp,然后ja|jb|je来的要慢吧?

@est 很简单啊, CMP 换成 SUB

就作者给出的例子来看，非常靠谱；文档title翻译略显蛋疼。。。

@mikawudi 认真了你就输了=w=

= =隐约记得重构那本书就说要用多态来着。。。
有点烦

@Golevka = -!你妹.....