【问题标题】:Coding style of "if" statements [duplicate]“if”语句的编码风格[重复]
【发布时间】:2016-04-19 15:40:44
【问题描述】:

最近我注意到一些程序员倒写“if”语句的风格。也就是说,在测试中,他们将常量值放在第一位,然后将他们正在测试的变量放在第二位。例如,他们写道:

bar = foo();
if (MY_CONSTANT == bar) {
    /*  then do something */
}

对我来说,这让代码有点难以阅读。因为我们真正谈论的是测试变量“bar”的值,而不是所有等于“MY_CONSTANT”的变量,所以我总是把变量放在第一位。它是一种不言而喻的语法。

无论如何,我看到一些程序员总是以相反的顺序执行此操作。此外,我只是在过去几年中才注意到这一点。我已经用 C 语言编程超过 25 年了,直到过去 4 年左右我才看到这一点。所以我的问题是:

人们这样做有什么原因吗?如果有,那是什么原因?这是某些语言或项目中的通用标准,还是在某些大学中教授?还是只有少数人想要与众不同?

【问题讨论】:

  • @vlad_tepesch 解释了为什么会出现这种风格;但使用与否主要是个人观点和风格的问题。
  • 尤达条件不使用你应该。它们是古老的,现代编译器已经警告将正常顺序。
  • 我认为这不是最近的事。大学的联系或许可以解释为什么它会持续存在。教授们厌倦了一次又一次地处理同一个错误,而制造这个错误的学生不太可能注意编译器警告。教学生这样写可以节省教授调试学生代码的时间。
  • @JohnColeman:这样的代码在像公司这样的专业环境中越来越被拒绝,因为编译器会在超过 10 年的时间里警告它们。教学生使用它们是错误的方法。更简单且更常见的做法是拒绝生成启用常见警告的诊断的代码。教授更有可能曾经以这种方式学会了它并且只是保持习惯。可悲的是,大多数教授不喜欢学习新技巧,如果它们对于他们感兴趣的领域并不是真正必要的。
  • 我从未见过尤达斯拒绝过。实际上,我更喜欢它们而不是“正常”构造,它偶尔会将实际条件从我的编辑/调试器窗口的 rhs 中推开,因为它是对具有 13 个参数的某些系统调用的结果进行检查。

标签: c coding-style


【解决方案1】:

这称为“Yoda-Style”(或“Yoda 条件”或“Yoda 符号”),应该可以防止您意外书写

if (bar = MY_CONSTANT) {
    /*  then do something */
}

因为

if (MY_CONSTANT = bar) {
    /*  then do something */
}

会触发编译器错误。

这个名字来源于星球大战角色尤达也在使用的不常见的扭曲句子结构。

在我看来,使用“Yoda-Style”会使代码更难理解,因为它违反了正常的句子构造规则。代码质量检查器(或者如 cmets 中提到的甚至可能是编译器本身)也应该抱怨这样的分配,所以(恕我直言)没有充分的理由混淆你的代码。

【讨论】:

  • 我希望这个问题的答案会更有价值。
  • 顺便说一句,这是最愚蠢的原因之一,因为有能力的编译器(或 linter)会警告条件中的赋值。
  • @Rhymoid 人们倾向于忽略编译器警告。这是唯一且充分的理由。顺便说一句,由于该构造是完全合法的,因此符合标准的编译器没有理由对此发出警告。
  • @EugeneSh。当您总是-Wall -Werror 时,您不能再真正忽略警告,这应该是所有生产代码的默认值。
  • @Rhymoid“应该是”和“实际上是”通常是两种不同的野兽......
【解决方案2】:

这是 15 年前左右有人认为最好的最佳实践。所谓的好处是它可以防止某人做意外的任务而不是比较。

这很可疑,现在它 100% 没有实际意义,因为任何值得使用的编译器都会警告分支运算符中的赋值,但成群的旅鼠仍然复制 最佳实践,甚至不考虑它的含义或它是干什么用的。

【讨论】:

  • 我经常有意地在条件句中执行分配,特别是对于bools,即if ((myBool=SomeBoolFunc()) == true){ // do stuff }else{ // do other stuff } // now I can return/use myBool without explicit assignment。它为我节省了 2 行来分配 bool 是真还是假 (if true, myBool = true, else myBool = false;)。我从这些被认为是不好的做法的答案/cmets 中获得了共识?
  • @yano,编译器会建议在这个赋值周围加上括号。没什么大不了的。
  • 好吧,那是另一回事。很确定我已经打开了警告,我想我从来没有见过有人警告我这个,但我总是确保先用括号来做作业,然后再做比较。谢谢
  • @yano 我认为这是不好的做法,因为它隐藏了条件中的副作用,如果条件得到增强,也可能导致错误,而没有提醒短路评估可能会破坏您的分配。
  • @yano 作为第二个评论:比较 bool 和 bool 常量很尴尬。首先这是不合逻辑的,因为结果也是一个布尔值,然后应该针对一个常数进行测试。第二:值 2 也将被认为是正确的,但如果 true 在内部被认为是 1 - 所以你正在测试 1==2(请注意,语言是 C,其基本形式没有 @ 987654327@ 类型 - 所以一定有人为此编写了一个依赖于整数数据类型的定义)
猜你喜欢
  • 2016-03-21
  • 1970-01-01
  • 1970-01-01
  • 2013-07-07
  • 2013-08-20
  • 2018-10-22
  • 1970-01-01
  • 2015-11-06
  • 1970-01-01
相关资源
最近更新 更多