除了代码可读性之外,为什么使用大量的if语句会很糟糕?
答案 0 :(得分:13)
您编写的每个if / else都会增加您必须测试的代码路径数。
答案 1 :(得分:11)
如果你有一个接一个的if语句,那么switch case语句会更有用。至少它对每个可能的inupt都有一个固定的响应时间,因为它不需要通过所有的if语句。
很多if(和else)语句通常表示
a)Violation of Single responsibility Principle
b)需要重构为Strategy Design Pattern
答案 2 :(得分:3)
嗯,我要问的问题是,“而不是什么”?
如果你的意思是与switch语句相反,那么除了可读性之外,有时更有效率。作为一个规则(当然在C#中,可能在其他中),在一定数量的分支之下,它将在编译时变成一系列if语句但超过该数字它将变成基于散列的查找和跳转平均情况下可能会更快。
或者,如果您对不同情况的相对频率有很好的了解,那么使用一组if语句可以提高效率。例如。如果95%的案例与第一个分支匹配,4%匹配第二个分支,1%匹配所有其余分支,这可以通过进行单个比较在95%的情况下提供更好的性能,在这种情况下甚至可能不分支。
因此。 可能在这种情况下可以提高效率。
但是,可读性仍然很重要。作为一个极端的例子,有一种图灵完备语言的设计只是为了看看图灵完整语言的编译器有多小。它的设计师将语言命名为“brainf ** k”。这本身就是对可读代码在实际编程中的重要性的一个很好的评论。
现在,对于大量if语句来说,一个更大的问题是,它通常表明您正在通过那些可以使用类层次结构更好地建模的if语句进行建模。在某种程度上,这只是对可读性的另一种看法(假设程序以任何一种方式工作)。然而,它是关于整个程序的可读性和可理解性。它将大大影响你对程序的心理模型,可扩展性和影响,而不仅仅是你可以维持它的程度,但你会想到它可能。它可以很容易地成为一个程序,它成为一个传统的时间沉,直到有人知道如何摆脱它,以及一个增长继续给予投资回报。
答案 3 :(得分:1)
有时候由于处理器架构,找到一种避免分支的方法会更有效率;这可能被视为if
陈述的缺点。
答案 4 :(得分:1)
Chusdad是对的。切换结构优于多个if-else。下一种方法是使用enum作为切换键。在这种情况下,如果您忘记在交换机中提及其中一个枚举元素,则会收到警告。
但如果您使用枚举和切换,请继续进行更好的设计:完全取消开关!
在枚举中声明抽象业务方法。为每个枚举元素实现它。调用enumElement.theMethod()而不是实现switch。
这是一个例子。
enum Foo {
ONE {
public void foo() {
// do something
}
},
TWO {
public void foo() {
// do something
}
},
;
public abstract void foo();
}
以下是使用此代码的代码:
Foo.valueOf(System.getProperty("foo")).foo();
将此行与以下内容进行比较:
String foo = System.getProperty("foo");
if("ONE".equals(foo)) {
//.....
} else if("ONE".equals(foo)) {
//.....
} else {
//.....
}
我认为不需要评论。
答案 5 :(得分:0)
if(A)
{
}else
if(B)
{
}else
if(C)
{
}else
if(D)
{
}else
{ }
所有if
s仍然必须“计算”,使其像“O(n)”。应尽可能避免使用switch(Lalala)
答案 6 :(得分:0)
另一种可能性 - 它取决于if语句的作用。在某些情况下,他们可以通过适当设计的类层次结构做出更好的决策。
你能否发布一些你被告知的陈述错误的例子?
答案 7 :(得分:0)
如果语句可以在管道中产生停顿。您可以阅读有关管道危害here的信息。因此,对于性能非常关键的应用程序,在大循环中使用许多if语句并不是一个好主意。另请参阅this关于现代处理器中分支预测的文章,以及各种if条件的基准。
另外,我看到很多人谈论案例陈述。检查this SO线程。
最后,wiki article关于可能每个程序员都应阅读的管道。
希望它有所帮助。
答案 8 :(得分:0)
如果您发现自己一遍又一遍地为相同的条件编写if
语句,那么构建类型层次结构的部分将更易于维护。
原因是如果此条件的逻辑发生变化,您将需要搜寻使用它的每个if
语句并对其进行修改。
如果该逻辑封装在类层次结构中,则只需更改一次。