两个单独的"如果",相同的条件 - 可以吗？

Question

您认为哪两个更好？

if (the_condition)
{
    variable = sth;
}
else
{
    variable = sth_else;
}

if (the_condition)
{
    variable_2.doSth();
}
else
{
    variable_2.doSthElse();
}

要么

if (the_condition)
{
    variable = sth;
    variable_2.doSth();
}
else
{
    variable = sth_else;
    variable_2.doSthElse();
}

我问它,因为第二个例子显然更短.另一方面,在第一个示例中,对不同变量的操作是分开的,因此可能更容易阅读.

你认为他们中的任何一个更好吗？或者提出这样一个问题毫无意义,因为它无关紧要？

Answer 1

#2

如果情况发生变化怎么办？然后你必须在n个地方更新它!(并且很容易错过一个,引入微妙的,难以发现的错误.)

我个人觉得#1更难阅读,因为我必须阅读每个作业的条件,因为它可能会有所不同.对于#2,我知道if正文中的所有内容都处于单一条件的上下文中 - 您可能会说条件封装了一个单一的,有凝聚力的多语句行为块.

当然,如果a的主体中的陈述if是无关的(即不是同一块行为的一部分),那么它们应该是分开if的.但这可能并非如此:您根据初始条件(可能是一个逻辑操作)设置变量.

Answer 2

重复条件没有理由不好,既不是性能(可能并不重要),也不进行维修(事做).

大多数程序员都不同意你对变量操作应该分开的看法.常见的观点是控制流程应尽可能简单,第二种选择就是这种情况.

Answer 3

已经给出了许多选择第二种选择的好理由,但还有另一种选择:第一种选择的结构与大多数人的想法不一致.你自己的大脑是这样的吗？

If I go to the store I'll buy milk.
If I go to the store I'll buy eggs.
If I go to the store I'll get cash from the ATM.

或者像这样？

If I go to the store I'll buy milk, buy eggs, and get cash from the ATM.

Answer 4

紧凑版; 我发现这个最具可读性,一般来说就是我如何处理它的代码... YMMV,当然.;)

// the safest way; it protects you from unexpected results in cases
// where the evaluation of "the_condition" has side-effects, or where
// it may be changed in the future to have them (as can often happen, 
// for instance, when a class field is changed to a property)
var theCondition = the_condition;

variable1 = theCondition ? sth           : sth_else;
variable2 = theCondition ? sth_different : sth_even_more_different;

// if evaluating "the_condition" has no side-effects, and you can be
// fairly sure it never will, then you can do this, but be careful:
variable1 = the_condition ? sth           : sth_else;
variable2 = the_condition ? sth_different : sth_even_more_different;

不是特定于任何特定答案,请记住(在结果可能多次使用的情况下),将结果分配给适当范围的变量(如果它们是瞬态的本地变量,或者当它们是对象或类(静态)属性时,则是优秀的做法.以更加永久的方式命名,以揭示结果的概念性质的方式(例如,不是变量1和变量2:D).

通过仅根据需要对事物进行评估,您将在概念上使代码更加清晰(假设您确实为分配评估的变量赋予了良好的名称),并且编译后的代码通常会更有效(并且几乎不会更少)有效).

[感谢Peter Wone在评论中建议多重评估的观点应该更明确.]

也可以使用以下内容:

        switch (the_condition)
        {
            case true:
                variable1 = sth;
                variable2 = sth_else;
                break;

            case false:
                variable1 = sth_different;
                variable2 = sth_even_more_different;
                break;

        }

虽然我认为很难成为合适的解决方案; 我提到它是完整的,因为我还没有看到它的建议.

正如我在下面的评论回复中提到的,case如果以下所有内容成立,则该声明的可能示例如下:

• 此检查在有限状态机内
• the_condition 代表FSM的状态
• the_condition类型FSM可能会在某些时候更改为枚举类型
  反射:
  • 在我看来,概念上表示除了真正的二进制[yes/no | off/on | true/false] -type选项之外的其他东西应该被视为二进制值之外的其他东西,因为:
    • 我认为,只要可行,代码应该代表概念而不是实现细节.
    • 选择一个布尔值来表示非二元选项将是您的实现的偶然特征,而不是选项的概念性质.
    • 即使在您可能永远不会将变量更改为枚举类型的情况下,这也很容易发生.
    • 并且,这符合可行性条件,因为case在这里代表这种选择是可行的.[这里有一个假设:要么这不是一个紧密的循环,要么编译器优化代码不比条件更强,或者代码执行可接受的无论如何.]
  实施例/推理:
  • 您正在编写一个自定义FSM,在某些条件下,必须从两个内部列表中的一个中选择项目,以提供一些熟练的算法实现:
    • 您正在使用的实现仅在选择项目时有效,每个列表一个,从前到后或从后到前.
    • 调用的布尔值UseFifoAlgorithm被选择为确定是以FIFO还是LIFO方式提取项目的属性.
    • 因此,在这种情况下,UseFifoAlgorithm表示前后选择,但其否定" !UseFifoAlgorithm"在概念上并不等同于"不要使用前后算法从列表中提取".但是,更确切地说,"使用从前到后的算法从列表中提取".
    • 否定价值并不意味着否定其背后的概念,使用否定价值作为代码中的决定因素并不代表概念上真正发生的事情,因此,它似乎不适合使用就这样.
    • 由于case语句是最能代表(概念上)在非二元可能性之间做出选择的构造,并且由于已经证明这不是(概念上)二元选择,因此该case语句是表示其性质的更合适的选择.比较.
    • 因此,假设代码对任务执行充分,该case语句是可行的,因此应该使用(可能使用高于'true'和'false'的注释指定选择哪种方法)而不是条件.

好吧,我知道,很多文本都是针对一个罕见的情况,但这是我想到的例子,因为我经常使用布尔值来维护或定义状态或选项,以避免创建枚举值.在其中一些案例中,我只是试图"尽可能地做最简单的事情",但在某些情况下我做出了一个糟糕的设计决定,因为我太不愿意创造那个列举的价值.

所以,已经证明有一些可能的情况,布尔确实可能适合这样的选择,我认为这个例子的最大价值在于,在这种情况下,我更有可能将此视为一种选择,因此也更有可能考虑布尔是否合适:当两种可能中的一种之间确实存在强制选择时,但是否定一种概念在概念上并不意味着第二种可能性.似乎在其他情况下,咬住子弹并创建它可能更好enum.

如果出于某种原因,不希望向enum类的用户或库的用户或者有什么用户公开额外的用户,那么仍然可能值得考虑使用enum内部来表示选择,然后使用int或多个布尔值或类似的东西,以向外界揭示选择.