强制使用牙套

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

我能提供的最好的反驳论点是，空间占用的额外行会减少您一次可以看到的代码量，而您一次可以看到的代码量是影响易用性的一个重要因素。是为了发现错误。我同意你给出的包含大括号的原因，但是在 C++ 的许多年里，我只能想到一次我因此犯了一个错误，而且是在一个我没有充分理由跳过大括号的地方反正。不幸的是，我无法告诉您这些额外的代码行在实践中是否有帮助。

我可能更有偏见，因为我喜欢在相同缩进级别匹配大括号的对称性（以及将包含的语句隐式分组为一个执行块） - 这意味着所有都添加大括号向项目添加了很多行。

Answer 2

我在一定程度上强制执行这一点，但对于计算结果为返回或继续循环的 if 语句有一些小例外。

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

if(true) continue;

As is this

if(true) return;

但规则是它要么是 return 要么是 continue，并且都在同一行上。否则，一切都要做好准备。

这样做的原因是为了有一个标准的方法，也是为了避免你提到的评论问题。

Answer 3

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

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

当你没有用大括号括住单行，然后有人将其注释掉时，你就有麻烦了。

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

1) 用单行注释掉单行之前的 if、while 等。 即像任何其他多行语句一样对待

if(foo)
    bar();

（例如，多行赋值或多行函数调用）：

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

2) 在 // 前面加上 ;：

if(foo)
;//    bar();

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

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

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

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

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

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

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

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

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

Answer 4

我还没有找到任何人提出不总是使用花括号的充分理由。

这些好处远远超过了我听过的任何“感觉丑陋”的理由。

编码标准的存在是为了使代码更易于阅读并减少错误。

这是一个真正能带来回报的标准。

Answer 5

我发现很难与减少错误并使代码更具可读性的编码标准争论。有些人一开始可能会觉得很难看，但我认为这是一个完全有效的实施规则。

Answer 6

我的立场是大括号应该根据缩进匹配。

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

while (things) 
{
    // stuff
}

就您的两个示例而言，我认为您的示例的可读性稍差，因为找到匹配的右括号可能很困难，但在缩进不正确的情况下更具可读性，同时允许更轻松地插入逻辑。这并不是一个很大的区别。

即使缩进不正确，if 语句也会执行下一条命令，无论它是否在下一行。不将两个命令放在同一行的唯一原因是调试器支持。

Answer 7

我看到的一大优点是，可以更轻松地向带花括号的条件和循环添加更多语句，并且不需要多次额外的击键即可在开始时创建花括号。

Answer 8

我个人的规则是，如果它是一个非常短的“if”，则将其全部放在一行中：

if(!something) doSomethingElse();

通常，我仅在连续出现一堆这样的 if 时才使用它。

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”、“始终使用断言验证参数”、“始终编写单元测试”与“始终添加一些大括号，即使不需要”） 。以前的规则每年将为您节省数千个错误。大括号规则可能会为你节省一个。也许吧。

• 保留最有效的规则，舍弃无用的东西。箔条至少是任何比忽略该规则可能出现的 bug 成本更高的规则。但如果您有超过 30 条关键规则，您的程序员可能会忽略其中的许多规则，而您的良好意愿将化为灰尘。

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

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

Answer 11

许多语言都有这样的语法（我特别想到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 之后立即调用，具有类似的参数模式，因此我想将重复的代码重构为新的 >组合函数。如果您没有足够强大的重构工具（^\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 语句应该有大括号以避免悬空的 else，但据我所知，您强制执行一种样式是因为担心，IMO，放错地方了。

Answer 15

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

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

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

  for (init; term;totalCount++)
  {
      // 故意留空
  }
  

无需以详细的方式对其进行标准化，只需说出以下内容即可：

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

Answer 16

我认为大括号的重要之处在于它们非常明确地表达了程序员的意图。您不必从缩进推断意图。

也就是说，我喜欢格斯建议的单行返回和继续。意图很明显，而且更清晰、更容易阅读。

Answer 17

如果您有时间阅读所有这些内容，那么您就有时间添加额外的大括号。

Answer 18

为了可维护性，我更喜欢在单行条件语句中添加大括号，但我可以看到不使用大括号如何看起来更干净。这并不困扰我，但有些人可能会因为额外的视觉噪音而失去兴趣。

我也无法提供更好的反驳。对不起！ ;)

Answer 19

对于这样的事情，我建议只为 IDE 的自动格式化程序提供一个配置模板。然后，每当您的用户按下 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

哇。 没有人知道悬空else问题？这本质上就是始终使用大括号的原因。

简而言之，else 语句可能会产生令人讨厌的模糊逻辑，尤其是当它们嵌套时。不同的编译器以自己的方式解决歧义。如果您不知道自己在做什么，那么放弃牙套可能会是一个大问题。

美观和可读性无关。