该if语句很少被视为“邪恶的”goto或可变的全局变量-甚至后者实际上也并非普遍且绝对不是邪恶的。我建议把这个说法有点夸张。
它还在很大程度上取决于您的编程语言和环境。在支持模式匹配的语言中，您将拥有强大的替换工具供if您使用。但是，如果您正在用C编程低级微控制器，则用if函数指针替换s将是朝错误方向迈出的一步。因此，我将主要考虑if在OOP编程中替换s，因为在功能语言中，if反正不是习惯用法，而在纯过程语言中，您没有很多其他选择。
但是，条件子句有时会导致难以管理的代码。这不仅包括该if语句，而且更常见的是该switch语句，该语句通常包含比相应语句更多的分支if。
在某些情况下，使用 if
当您编写实用程序方法，扩展或特定的库函数时，很可能将无法避免ifs（并且您不应该）。没有更好的方法来编写此小函数，也没有使其比它更能自我记录的代码：
int Min(int a, int b)
{
if (a < b)
return a;
else
return b;
}
int Min(int a, int b)
{
return (a < b) ? a : b;
}
分支“类型代码”是一种代码味道
另一方面，如果遇到测试某种类型代码的代码，或者测试某个变量是否为某种类型的代码，则这很可能是重构的好选择，即用多态替换条件。
这样做的原因是，通过允许调用者在某个特定类型的代码上分支，您将有可能最终在代码中散布大量检查，从而使扩展和维护变得更加复杂。另一方面，多态使您可以使此分支决策尽可能接近程序的根。
考虑：
void RunVehicle(Vehicle vehicle)
{
if (vehicle.Type == CAR)
Drive(vehicle);
else if (vehicle.Type == PLANE)
Fly(vehicle);
else
Sail(vehicle);
}
通过将常见但特定于类型的（即特定于类的）功能放在单独的类中，并通过虚拟方法（或接口）将其公开，您可以允许程序的内部将此决定委派给调用层次结构中较高的人员（可能位于代码的单个位置），从而使测试（模拟），可扩展性和维护更加容易：
interface IVehicle
{
void Run();
}
void RunVehicle(IVehicle vehicle)
{
vehicle.Run();
}
现在，您可以轻松测试您的RunVehicle方法是否可以正常工作：
var mock = new Mock<IVehicle>();
something.RunVehicle(mock.Object);
mock.Verify(m => m.Run(), Times.Once());
仅if条件不同的模式可以重复使用
关于if在您的问题中用“谓词”替换的说法，Haines可能想提到有时在您的代码上存在相似的模式，只是它们的条件表达式不同。条件表达式的确与ifs结合出现，但是整个思想是将重复模式提取到单独的方法中，而将表达式作为参数。这是LINQ已经做的，与替代方法相比，通常可以使代码更简洁foreach：
考虑以下两种非常相似的方法：
public double AverageMaleAge(List<Person> people)
{
double sum = 0.0;
int count = 0;
foreach (var person in people)
{
if (person.Gender == Gender.Male)
{
sum += person.Age;
count++;
}
}
return sum / count;
}
public double AverageFemaleAge(List<Person> people)
{
double sum = 0.0;
int count = 0;
foreach (var person in people)
{
if (person.Gender == Gender.Female)
{
sum += person.Age;
count++;
}
}
return sum / count;
}
这表明您可以将条件提取到谓词中，这两种情况（以及将来的许多其他情况）都只有一个方法：
public double AverageAge(List<Person> people, Predicate<Person> match)
{
double sum = 0.0;
int count = 0;
foreach (var person in people)
{
if (match(person))
{
sum += person.Age;
count++;
}
}
return sum / count;
}
var males = AverageAge(people, p => p.Gender == Gender.Male);
var females = AverageAge(people, p => p.Gender == Gender.Female);
而且由于LINQ已经有很多方便的扩展方法，所以您实际上甚至不需要编写自己的方法：
var males = list.Where(p => p.Gender == Gender.Male).Average(p => p.Age);
var females = list.Where(p => p.Gender == Gender.Female).Average(p => p.Age);
在最后的LINQ版本中，该if语句已完全“消失”，尽管：
- 老实说，问题不在
if于其本身，而在于整个代码模式（仅仅是因为它是重复的），并且
- 在
if仍实际存在，但它写在里面LINQWhere扩展方法，它已经过测试和修改关闭。减少自己的代码总是一件好事：减少测试的事情，减少出错的事情，并且使代码易于遵循，分析和维护。
大量的嵌套if/else语句
当您看到一个跨越1000行并包含数十个嵌套if块的函数时，很有可能将其重写为
- 使用更好的数据结构并以更适当的方式组织输入数据（例如，哈希表，该哈希表将在单个调用中将一个输入值映射到另一个输入值），
- 使用一个公式，一个循环，或者有时仅使用一个现有的函数，该函数在10行或更少的行内执行相同的逻辑（例如，我想到这个臭名昭著的示例，但一般的想法也适用于其他情况），
- 使用保护子句防止嵌套（保护子句使整个函数的变量状态更有信心，因为它们会尽快消除异常情况），
- 至少
switch在适当情况下以声明代替。
当您感觉到它是代码的味道时进行重构，但不要过度设计
说了这么多，您不应该在现在和那里有条件的情况下度过不眠之夜。虽然这些答案可以提供一些一般的经验法则，但能够通过经验检测出需要重构的最佳方法。随着时间的流逝，出现了一些模式，导致一遍又一遍地修改相同的子句。
if陈述就像锤子一样是邪恶的。有些人可能会滥用它们，但是它们是必不可少的工具。