【问题标题】:One line if statements [closed]一行if语句[关闭]
【发布时间】:2009-09-16 18:40:58
【问题描述】:

我最近与一位同事发生了一场争论,涉及一行 if 语句,想看看 stackoverflow 是怎么想的。

你觉得语句应该写成:

if(condition)
{
     statement = new assignment;
}

if(condition)
    statement=new assignment;

请为您的决定提供充分的理由。

【问题讨论】:

  • 通过您的编辑,您已经完全改变了问题;-)
  • 我查看了编辑历史记录,在您提出问题后进行了两次编辑:重新标记,以及试图使其成为实际问题的代码格式化。整体含义没有改变。
  • @geowa:当然可以。代码“格式化”改变了问题的性质。主题是指“单行 if 语句”。第一个示例现在采用 行,第二个示例采用 two
  • @Adam:如果您查看原始问题,它的写法与现在完全一样。但是 OP 没有正确设置代码格式,因此它显示为 single 语句。我同意,之前和之后的编辑改变了问题的含义,但是从最初编写的内容(包括格式)来看,我相信它现在的显示方式是 OP 的意图。

标签: if-statement


【解决方案1】:

如果你真的应该使用一行 if

 if(condition) statement=new assignment;

会更好,因为它只有一行,它应该包含一个操作。

【讨论】:

  • +1,因为基本上,如果你需要大括号,你不会写在一行中。
  • 永远不要这样做,拜托。如果您必须调试,这是纯粹的癌症。在调试时,您永远不知道条件是否为 True 并且语句已设置!你总是需要做复查。更糟糕的是,如果在if 之后有一个休息时间......在地狱中肯定有一个特殊的地方供人们这样做。
  • 调试起来简直太可怕了,而且绝对不容易阅读。
  • 这个想法是为了防止人们将语句添加到没有大括号的 if 中。我个人仅将它用于中断和继续,并且不容忍使用没有大括号的 if。如果它不能在一行中执行两条语句,我认为你需要升级你的调试器。
【解决方案2】:

我总是使用大括号来减少某人(包括我自己)稍后通过编辑 if 语句周围的代码而引入错误的风险,而没有仔细注意哪些行属于 if 条件的一部分。

编辑:

如果我碰巧在一些旧代码中遇到这种情况,这里是一个活生生的例子:

if (form.validateUpload (messages, this))
    return getErrorOutcome (ctx, messages);
    if (LOG.isInfoEnabled ())
        LOG.info ("CREATING UPLOAD");

请注意两个“if”语句都在主代码块中,但由于格式不佳,乍一看它们似乎是嵌套的。当然,任何“优秀”的程序员都应该很快看到发生了什么,但为什么会引起不必要的混乱呢?

【讨论】:

  • 这种嵌套 IF 语句很危险,应该避免。但这并不意味着 all 如果语句不好的话。例如,函数体中的if(somethingBad) returnif(something) doSomethingElse() 增加了IMO 的大量可读性。
【解决方案3】:

我一直是牙套的粉丝。如果有人像这样修改单行 if 语句:

if(condition) statement=new assignment;

if(condition)
statement = new assignment;
another statement;

您不会得到预期的行为。

使用大括号几乎可以确保如果有人修改了 if 语句,他们会确保将正确的语句放在正确的位置。

【讨论】:

  • 如果有人这样做,他们显然不懂语言。这不属于基本能力吗? (诚​​心诚意)
  • 理解语言和打错字没有任何关系。添加大括号确保无论如何都会发生正确的行为。
  • 也许吧。可能是初级程序员在第一次编写代码后很好地维护代码。也可能是一个糟糕的一天的高级程序员。为什么要为某人犯错创造机会?
  • 所以你建议用许多不必要的大括号乱扔代码。
  • @Alan - 我们不能对我们的代码进行白痴证明。任何不了解这种基本语言行为的人都需要快速学习语言。他们显然不知道,也不应该玩弄你的代码,而且他们引入的任何错误都可以 a) 由有能力的人轻松修复,b) 可能会教给他们一些他们显然需要艰难学习的东西.我使用单线样式,并且从未成为这个特定错误的牺牲品。这是一个如此广泛和广泛的警告“陷阱”,以至于没有人再上当了。
【解决方案4】:

这实际上取决于您小组的编码风格。该组应具有一致的编码标准。对于我目前的小组,我们总是使用:

if (condition) {
  statement = new assignment;
}

我们这样做是为了防止忘记 if 语句后的大括号而导致的错误,例如:

if (condition)
   statement1;
   statement2; 
//statement2 is not part of the if statement, but it looks like it because of wrong indentation

直到最近,我与之共事的另一个小组总是将这种语法用于单行 if 语句:

if (condition)
    statement1;

我个人不太喜欢这个,因为它不太明确;但最重要的是为您的团队或项目坚持一致的编码标准,以便您编写的代码看起来像您的同事编写的代码,并且对团队中的每个人都一样容易阅读。

您的 IDE 或环境的约定可以为您的编码标准提供良好的基础,甚至可以根据您的团队的风格进行定制。

【讨论】:

    【解决方案5】:

    我总是使用无括号的单行 if 语句。括号的存在表明(语法正确)“哦,我可以在这里做其他事情......”而且我不喜欢这种诱惑。任何涉及多个语句的内容都应该用适当的括号分成多行。

    【讨论】:

      【解决方案6】:
      if(condition)
          statement=new assignment;
      

      if(condition) statement=new assignment;
      

      【讨论】:

        【解决方案7】:
        if (condition)
        {
            statement = new assignment;
        }
        

        是我要写的。那是因为我喜欢整洁的代码,这样可以节省阅读/编辑/理解的时间。

        在极少数情况下,我通常只会在我快速而肮脏地编写代码以进行调试等时才进行异常处理。

        单行 if 语句总是很容易被分号的放置方式破坏。

        【讨论】:

        • 什么定义了“整洁的代码”?这是相当主观的。我认为在 if 之后放置大括号会不必要地占用一整行。
        【解决方案8】:

        我会不带括号。

        您需要括号的唯一原因是如果您在块内有多个语句。

        不过,这听起来像是在浪费争论。

        【讨论】:

          【解决方案9】:

          作为一项规则,我讨厌单行 ifs,除非在这种 Perl 案例中

          operation if condition;
          

          【讨论】:

          • 与 JuanZe 一样,这不是一个答案。问题是关于如何做单行,而不是他是否应该做。
          【解决方案10】:

          我有自动格式化设置来杀死你的单行,它把它放在两行。因此,它需要大括号。

          【讨论】:

          • 我很好奇为什么这么多人回复不相关的答案。同样,问题是关于如何形成单线,而不是是否应该
          • 这不是无关紧要的。在我的格式控制源存储库中没有一行。它根本不存在,因此担心这个问题是无关紧要的。
          • 此外,OP 询问了偏好。我给了我的。您的评论无关紧要,因为您显然没有阅读该问题。
          【解决方案11】:

          我总是用括号括起来,我从不写一行 ifs,我的方法是这样的

          if(condition) { 
              statement = new assignment; 
          }
          

          因为我编写 Java 代码,这是该语言的惯例。检查:

          http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449

          注意:if 语句总是使用大括号 {}。避免以下容易出错的情况 形式:

          if (condition) //AVOID! THIS OMITS THE BRACES {}!
              statement;
          

          括号的使用可以防止错误:其他一些人可以添加以后应该执行的新句子,如果条件和忘记括号

          【讨论】:

            猜你喜欢
            • 2019-02-21
            • 2017-09-05
            • 2016-10-15
            • 2017-05-24
            • 2014-10-21
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多