冗余检查条件是否不好？

我经常在代码中找到一些位置，一遍又一遍地检查特定条件。

我想举一个小例子：假设有一个文本文件，其中包含以“ a”开头的行，以“ b”开头的行以及其他行，而我实际上只想使用前两种行。我的代码看起来像这样（使用python，但将其读取为伪代码）：

# ...
clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if (line.startsWith("a")):
        # do stuff
    elif (line.startsWith("b")):
        # magic
    else:
        # this else is redundant, I already made sure there is no else-case
        # by using clear_lines()
# ...

您可以想象我不仅会在这里检查这种情况，而且可能还会在其他功能中等等。

您认为它是噪声还是给我的代码增加了一些价值？

这是一种超乎寻常的惯例，处理它的方法是通过高阶滤波器。

本质上，您将一个函数以及要过滤的列表/序列传递给filter方法，结果列表/序列仅包含所需的那些元素。

我不熟悉python语法（尽管它确实包含上面链接中所示的功能），但是在c＃/ f＃中看起来像这样：

C＃：

var linesWithAB = lines.Where(l => l.StartsWith("a") || l.StartsWith("b"));
foreach (var line in linesWithAB)
{
    /* line is guaranteed to ONLY start with a or b */
}

f＃（假设为ienumerable，否则将使用List.filter）：

let linesWithAB = lines
    |> Seq.filter (fun l -> l.StartsWith("a") || l.StartsWith("b"))

for line in linesWithAB do
    /* line is guaranteed to ONLY start with a or b */

因此，要明确一点：如果使用经过验证的代码/模式，这是不好的样式。那样，通过clear_lines（）在内存中更改列表的方式将失去线程安全性，并失去您本可以拥有的并行性的希望。

最近，我不得不使用Motorola S-record格式实现固件编程器，与您所描述的非常相似。由于时间紧张，我的初稿忽略了冗余，并根据我实际需要在应用程序中使用的子集进行了简化。它很容易通过我的测试，但是一旦有人尝试过，它就失败了。没有任何问题的线索。它贯穿了整个过程，但最终失败了。

因此，我别无选择，只能执行所有冗余检查，以缩小问题所在。之后，我花了大约两秒钟的时间才找到问题。

正确的方法可能要花我两个多小时，但是在排查方面却浪费了别人的时间。很少有几个处理器周期值得浪费一天的故障排除时间。

话虽这么说，在涉及读取文件的地方，将软件设计为可以同时读取和处理一行而不是将整个文件读取到内存中并在内存中进行处理通常是有益的。这样，它仍然可以在非常大的文件上运行。

您可以提出例外else情况。这样就没有多余。异常是指不应该发生但要进行检查的事情。

clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if (line.startsWith("a)):
        # do stuff
    if (line.startsWith("b")):
        # magic
    else:
        throw BadLineException
# ...

在按合同设计时，人们猜测每个功能必须按照其文档中所述进行工作。因此，每个功能都有一个先决条件列表，即功能输入的条件，以及后置条件，即功能输出的条件。

该功能必须向其客户保证，如果输入符合前提条件，则输出将如后置条件所描述。如果不满足至少一个前提条件，则该函数可以执行所需的操作（崩溃，返回任何结果，...）。因此，前置条件和后置条件是功能的语义描述。

多亏了合同，一个功能可以确保其客户正确使用了该功能，而一个客户可以确保该功能可以正确完成其工作。

一些语言本机处理或通过专用框架处理合同。对于其他人来说，最好的办法就是使用asserts来检查前置条件和后置条件，如@Lattyware所说。但是我不会称之为防御性编程，因为在我看来，这个概念更侧重于针对（人类）用户输入的保护。

如果您利用合同，则可以避免冗余检查的情况，因为被调用函数可以完美地工作并且您不需要双重检查，或者被调用函数功能失调，并且调用函数可以按需运行。

然后最困难的部分是定义哪个功能负责什么，并严格记录这些角色。

实际上，您一开始就不需要clear_lines（）。如果行既不是“ a”也不是“ b”，则条件触发器根本不会触发。如果要摆脱这些行，则将else放入clear_line（）中。就目前而言，您正在对文档进行两次遍历。如果您在开始时跳过clear_lines（）并将其作为foreach循环的一部分进行操作，则可以将处理时间减少一半。

这不仅是糟糕的风格，而且在计算上也很糟糕。

如果您发现有无效的字符串（例如输出调试文本）而实际上想做任何事情，那么我说那绝对没问题。当由于某种未知的原因而停止工作时，还有几行额外的代码和几个月的时间，您可以查看输出以找出原因。

但是，如果只是忽略它是安全的，或者可以确定您永远不会获得无效的字符串，那么就不需要额外的分支。

就我个人而言，我始终会为任何意外情况至少输入一个跟踪输出-当您遇到附有输出的错误（确切告诉您出了什么问题）时，这样做会使工作变得更加轻松。

……假设有一个文本文件，其中包含以“ a”开头的行，以“ b”开头的行以及其他行，而我实际上只想使用前两种行。我的代码看起来像这样（使用python，但将其读取为伪代码）：

# ...
clear_lines() # removes every other line than those starting with "a" or "b"
for line in lines:
    if ...

我讨厌if...then...else建筑。我会避免整个问题：

process_lines_by_first_character (lines,  
                                  'a' => { |line| ... a code ... },
                                  'b' => { |line| ... b code ... } )