在条件陈述中检查"真实性"或"平等性"的做法 - 它真的有意义吗？

Question

我记得很多年前,当我在学校时,我的一位计算机科学老师告诉我们,最好检查条件的"真实性"或"平等性",而不是"不平等"等负面的东西.

让我详细说明 - 如果可以通过检查表达式是真还是假来编写条件代码,我们应该检查'真实性'.

示例:查明数字是否为奇数 - 可以通过两种方式完成:

if ( num % 2 != 0 )
{
  // Number is odd
}

要么

if ( num % 2 == 1 )
{
  // Number is odd
}

(请参阅标记的答案以获得更好的示例.)

当我开始编码时,我知道这num % 2 == 0意味着数字是偶数,所以我只是在!那里检查它是否是奇数.但他就像'不要检查不是条件.尽可能检查条件的"真实性"或"平等性".他建议我使用第二段代码.

我不赞成或反对,但我只是想知道 - 它有什么不同？请不要回复'技术上输出将是相同的' - 我们都知道.这是一般的编程实践还是他自己的编程实践,他在向别人讲道？

注意:我没有理由使用C#/ C++样式语法.在VB等中使用运算符时IsNot,我的问题同样适用<>.所以'!'的可读性 运营商只是其中一个问题.不是问题.

Answer 1

当项目后期添加更多条件时,问题就出现了 - 我正在研究的项目之一随着时间的推移稳定地收集条件(然后其中一些条件被移入struts标签,然后一些条件转移到JSTL .. .) - 一个否定不难阅读,但5+是一场噩梦,特别是当有人决定重组并否定整个事情时.也许在一个新项目上,你会写:

if (authorityLvl!=Admin){
 doA();
}else{
 doB();
}

在一个月后回来看看,它变成了:

if (!(authorityLvl!=Admin && authorityLvl!=Manager)){
 doB();
}else{
 doA();
}

还是很简单,但还需要一秒钟.
现在再给它5到10年腐烂.
(x%2!= 0)肯定不是问题,但也许避免上述情况的最佳方法是教导学生不要使用负面条件作为一般规则,希望他们之前会使用某些判断他们这样做 - 因为只是说它可能成为一个维护问题可能不是足够的动力.

作为附录,编写代码的更好方法是:

userHasAuthority = (authorityLvl==Admin);
if (userHasAuthority){
 doB();
else{
 doA();
}

现在未来的编码器更有可能只添加"|| authorityLvl == Manager",userHasAuthority更容易进入一个方法,即使条件被重组,它也只会有一个负数.此外,在应用De Morgan定律时,没有人会在应用程序中添加安全漏洞.