强制使用牙套

Question

作为我不久前写的代码标准文档的一部分，我强制要求“您必须始终对循环和/或条件代码块使用大括号，即使（特别是）它们只有一行。”

例子：

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

当你不加括号，然后有人将其注释掉时，你就有麻烦了。如果您不使用单行大括号，并且缩进在其他人的机器上显示不一样......你有麻烦了。

那么，问题：有充分的理由说明为什么这是一个错误的或不合理的标准吗？关于它已经有一些讨论，但没有人能给我提供比“感觉丑陋”更好的反驳。

Answer 1

我执行这一定程度上，用少数例外为如果其取值为返回或继续的循环语句。

所以，这是正确的我的标准：

if(true) continue;

由于是这样的

if(true) return;

但规则是，它可以是一个返回或继续，它是所有在同一行上。否则，括号为一切。

在推理既是具有这样做的一种标准的方式的缘故，并避免你提到的评论问题。

Answer 2

我可以提供最好的反驳是，通过空间占用多余的线（S）减少的代码，你可以在同一时间看到你可以一次看量，代码量是一个很大的因素在多么容易发现错误。我同意你给了包括括号的原因，但在多年的C ++我只能想到一个场合时，我犯了一个错误的结果，它是在一个地方，我没有很好的理由跳过括号无论如何。不幸的是我不能告诉你，如果看到这些代码行额外曾帮助在实践中还是不行。

我也许更偏向因为我喜欢在相同缩进级别匹配的括号的对称性（和所包含的语句的隐含分组为执行中的一个块） - 这意味着添加括号所有的时间增加了很多线到该项目。

Answer 3

我认为这条规则太过分了。严酷的标准并不能造就优秀的程序员，它们只是降低了懒虫搞砸的可能性。

您给出的示例是有效的，但它们有比强制大括号更好的解决方案：

当你不加括号，然后有人将其注释掉时，你就有麻烦了。

有两种做法可以更好地解决这个问题，选择一种：

1）注释掉 if, while, ， ETC。在单行与单行之前。IE。对待

if(foo)
    bar();

与任何其他多行语句一样（例如多行赋值或多行函数调用）：

//if(foo)
//    bar();

2) 前缀 // 与一个 ;:

if(foo)
;//    bar();

如果您不使用单行大括号，并且缩进在其他人的机器上显示不一样......你有麻烦了。

不你不是;代码的工作原理相同，但更难阅读。修复你的缩进。选择制表符或空格并坚持使用。 不要混合使用制表符和空格进行缩进。 许多文本编辑器会自动为您修复此问题。

编写一些 Python 代码。这至少可以纠正一些不良的缩进习惯。

另外，像这样的结构 } else { 在我看来就像是网络黑客版的 TIE 战斗机。

有充分的理由说明为什么这是一个错误的或不合理的标准吗？关于它已经有一些讨论，但没有人能给我提供比“感觉丑陋”更好的反驳。

多余的大括号（和括号）会造成视觉混乱。视觉混乱使代码更难阅读。代码越难阅读，就越容易隐藏错误。

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

强制大括号无助于发现上述代码中的错误。

附：我是“每条规则都应该说明原因”学派的订阅者，或者正如达赖喇嘛所说，“了解规则，以便你可以正确地打破它们。”

Answer 4

我还没有任何人对拿出一个很好的理由并不总是使用大括号。

好处远远超过任何“感觉丑”我听说过的原因。

编码标准存在使代码更容易阅读和减少错误。

这是一个标准的，真正回报。

Answer 5

我觉得很难与编码减少错误，并进行代码的可读性标准争辩。它可能觉得难看一些人在第一，但我认为这是实现一个完全有效的规则。

Answer 6

我站在那个撑杆应根据压痕匹配地面。

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

至于你的两个例子中，我会考虑，因为找到匹配闭括号可很难你的略少可读的，但是在例更可读的，其中压痕不正确，同时允许逻辑被插入更容易。这不是一个巨大的差异。

即使缩进不正确，if语句将执行下一个命令，不管它是否是下一行还是不行。为在同一行上不把两个命令的唯一原因是为了调试器支持。

Answer 7

在一个很大的优势我看到的是，它更容易添加更多的语句条件和循环所支撑，并且它并不需要许多额外的按键在开始创建大括号。

Answer 8

我个人的原则是，如果它是一个很短的“如果”，然后把它全部在一行上：

if(!something) doSomethingElse();

一般来说，我使用此仅当有连续一堆这样的IFS

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

这种情况不会经常发生，虽然，所以否则，我总是用括号。

Answer 9

目前，我有一个团队，该标准的生活工作，而我给它耐，我遵守了均匀的缘故。

我反对出于同样的原因我反对禁止使用异常或模板或宏的团队：如果您选择使用的语言，使用整个语言的如果括号中的C是可选和C ++和Java，按照惯例，规定它们示出了语言本身的一些恐惧。

我了解这里的其他答案中描述的危害，我理解为统一的向往，但我不是同情的语言的子集的除了一些严格的技术原因的，诸如用于某些环境仅有的编译器不容纳模板，或相互作用与C语言代码排除广泛用途的异常。

我的大部分日子组成审查提交的初级程序员，以及出现的什么都没有做支具放置或语句在错误的地方清盘的常见问题的变化。危害被夸大了。我宁愿用我的时间专注于更多的材料问题不是找违反什么样的编译器会愉快地接受。

Answer 10

一群程序员能够很好地遵循编码标准的唯一方法是将规则的数量保持在最低限度。

平衡收益与成本（每条额外的规则都会让程序员感到困惑，并且在达到一定阈值后，实际上会降低程序员遵循任何规则的机会）

因此，制定编码标准：

• 确保你可以用明确的证据来证明每条规则的合理性，证明它比其他规则更好。

• 看看该规则的替代方案 - 真的需要吗？如果所有程序员都很好地使用空格（空行和缩进），则 if 语句非常容易阅读，并且即使是新手程序员也不可能将“if”内的语句误认为是独立的语句。如果您遇到许多与 if 作用域相关的错误，根本原因可能是您的空白/缩进样式不佳，导致代码不必要地难以阅读。

• 根据规则对代码质量的可衡量影响来确定规则的优先级。通过执行规则可以避免多少错误（例如“始终检查 null”、“始终使用断言验证参数”、“始终编写单元测试”与“始终添加一些大括号，即使不需要它们”）。以前的规则每年将为您节省数千个错误。大括号规则可能会为你节省一个。或许。

• 保留最有效的规则，并丢弃糠秕。箔条至少是任何比忽略该规则可能出现的错误花费更多成本的规则。但如果你有超过 30 条关键规则，你的程序员可能会忽略其中的许多规则，而你的良好意愿将化为灰尘。

• 解雇任何在不阅读代码的情况下注释掉随机代码的程序员:-)

附：我对于支撑的立场是：如果“if”语句或其内容都是单行，则可以省略大括号。这意味着，如果您的 if 包含一行注释和一行代码，则内容需要两行，因此需要大括号。如果 if 条件跨越两行（即使内容是一行），那么您需要大括号。这意味着您只能在琐碎、简单、易于阅读的情况下省略大括号，而在实践中永远不会犯错误。（当语句为空时，我不使用大括号，但我总是添加注释，清楚地表明它是空的，并且是故意这样做的。但这与另一个主题接壤：在代码中明确，以便读者知道您的意思是范围为空，而不是电话响了而您忘记完成代码）

Answer 11

许多languanges有这样一个衬垫（我特别想到的perl）语法来处理这种“丑陋”。所以是这样的：

if (foo)     
//bar
else     
//baz

可以写为使用三元运算符三元：

foo ? bar : baz

和

while (something is true)
{
blah 
}

可以写为：

blah while(something is true)

然而，在没有这个“糖”语言我肯定会包括括号。像你说其防止从爬行在不必要的错误，使程序员的意图清楚。

Answer 12

我并不是说这是不合理的，但在15年与C的语言编码的，我还没有与省略括号一个单一的问题。注释掉分支听起来像理论的一个现实问题 - 我只是从来没有见过它在实践中发生的事情

Answer 13

总是使用括号的另一个优点是，它使得搜索和替换和类似的自动化操作更加容易。

例如：假设我注意到functionB后立即functionA通常称为，具有的参数类似的模式，因此我想重构该复制的代码到一个新的combined_function。一个正则表达式可以很容易地处理这个重构，如果你没有足够强大的重构工具（^\s+functionA.*?;\n\s+functionB.*?;），但是，没有括号，一个简单的正则表达式的方法可能会失败：

if (x)
  functionA(x);
else
  functionA(y);
functionB();

将成为

if (x)
  functionA(x);
else
  combined_function(y);

更复杂的正则表达式会在这种特殊情况下工作，但我发现它非常方便，能够使用正则表达式为基础的搜索和替换的，一次性的Perl脚本，和类似的自动化代码维护，所以我更喜欢的编码样式，这并不使该不必要复杂。

Answer 14

我不买你的论点。就个人而言，我不知道谁是有史以来“意外”的if下添加第二行。我会明白说的嵌套的if语句应该有括号，以避免悬空人，但在我看来你是强制由于担心，国际海事组织，是错误的风格。

Answer 15

以下是我遵循的不成文的（我想到目前为止）规则。我相信它在不牺牲正确性的情况下提供了可读性。它基于这样一种信念：在很多情况下，短格式比长格式更具可读性。

• 如果出现以下情况，请始终使用大括号： 任何 块的 if/else if/else 语句有多于一行。注释计数，这意味着条件中任何位置的注释意味着条件的所有部分都得到大括号。
• 可以选择在以下情况下使用大括号： 全部 语句块恰好是一行。
• 切勿将条件语句与条件放在同一行。if 语句后面的行始终是有条件执行的。

• 如果条件语句本身执行必要的操作，则形式将是：

  for (init; term; totalCount++)
  {
      // Intentionally left blank
  }
  

当您只需说出以下内容时，无需以详细的方式对此进行标准化：

切勿以牺牲可读性为代价而忽略大括号。如有疑问，请选择使用牙套。

Answer 16

我想括号最重要的事情是，他们非常明确地表达了程序员的意图。你不应该来推断压痕意图。

这就是说，我喜欢单行返回并继续由Gus建议。这样做的目的是显而易见的，并且它是清洁和更容易阅读。

Answer 17

如果你有过这一切的时间来阅读，那么你必须添加额外的括号的时间。

Answer 18

我宁愿将牙套单行条件语句的可维护性，但我可以看到如何做没有括号看起来比较清爽。它不打扰我，但有些人可以通过额外的视觉噪声被关闭。

我也不能提供更好的反驳。抱歉! ;）

Answer 19

这样的事情，我会建议只是未来与你的IDE的autoformatter的配置模板。然后，当用户按下Alt-Shift-F键（或任何按键在你选择的IDE）中，支架将被自动添加。然后只是说给大家：“继续前进，更改字体颜色，PMD设置或什么，请不要更改缩进或自动撑规则，虽然”

这利用的工具提供给我们，以避免争论的东西，真的是不值得的选项通常用在它的氧气。

Answer 20

的语言的根据 下，具有用于单一衬条件语句或循环语句括号不是强制性的。事实上，我会删除他们有更少的代码。

C ++：

版本1：

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

版本2：

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C＃：

版本1：

foreach(string s in myList)
   Console.WriteLine(s);

版本2：

foreach(string s in myList)
{
   Console.WriteLine(s);
}

根据你的角度看，版本1或2版会更具有可读性。答案是相当的主观

Answer 21

哇。 NO ONE 的是了解晃来晃去别的问题的？这基本上是在的原因总是使用括号。

在简单地说，你可以有else语句讨厌暧昧的逻辑，特别是当他们嵌套。不同的编译器解决自己的方式模糊。它可以是一个巨大的问题离开过牙套，如果你不知道自己在做什么。

美学和可读性无关了。