是否有人可以挑战鲍勃叔叔，因为他喜欢移除“无用的牙套”？

#1 楼

可读性不是一件小事。

当涉及到用单个方法括起来的括号时，我的想法很复杂。我个人删除它们是为了处理诸如单行返回语句之类的事情，但是实际上遗忘了这些括号确实在我最后工作的地方非常困扰我们。有人在if语句中添加了一行代码，但未同时添加必要的花括号，并且由于它是C语言，因此它使系统崩溃而没有警告。

我从不挑战任何信奉宗教的人，因为他们以后总是使用花括号这么小的惨败。

所以我看到了可读性的好处，但是我敏锐地意识到当您把这些大括号留在外面时会出现的问题。

我不会尝试寻找研究或某人发表的意见。每个人都有一个（就是这样的观点），并且因为这是一个风格问题，所以一个观点几乎与其他观点一样好。自己考虑问题，评估利弊，并下定自己的想法。如果您工作的商店的编码标准可以解决此问题，请遵循该准则。

#2 楼

您可以在此处，此处或在任何地方涂上自行车棚的地方找到数种已发布的促销活动或拒绝使用不支撑样式的内容。

远离自行车棚，请记住2014年的OS X / iOS SSL错误？

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

是的，由无括号块“引起” https://www.imperialviolet.org/2014/02/22/applebug.html

首选项可能取决于花括号的样式。如果我不得不写

if (suiteSetup)
{
    includePage(mode, suiteSetup);
}

我可能也倾向于节省空间。但是

if (suiteSetup) {
    includePage(mode, suiteSetup);
}

仅使用一条“额外”行。


我知道你没有问，但是我是否我一个人工作，我是一个异端。如果我删除括号，我更喜欢

if (suiteSetup != null) includePage(mode, suiteSetup);

它与iOS SSL样式的错误没有相同的视觉问题，但比起保存更多的“不必要的”行Bob叔叔确实做过;）如果您习惯它，就会读起来很好，并且在Ruby（includePage(mode, suiteSetup) unless suiteSetup.nil?）中具有主流用法。哦，知道了很多意见。

#3 楼

鲍勃叔叔对这种错误有很多防御措施，当“总是使用牙套”成为普遍的智慧时，这种错误并不常见：


个人对单行条件的强烈偏爱，因此多行程序脱颖而出并受到额外的审查。
当您插入第二行时，编辑器会自动退出。
他不断运行的整套单元测试。
集成测试。
在合并其代码之前进行同行评审。
由连续集成服务器重新运行所有测试。
由产品质量部门进行测试。

我认为，如果有人向鲍勃叔叔发表挑战，他将对以上几点有很好的反驳。这是提早发现的最简单的错误之一。

#4 楼

在大多数情况下，这是个人喜好，但是仍然需要考虑一些事情。

可能的错误

可以说，由于忘记了加载项而导致的错误大括号很少见，据我所知，它们确实偶尔会发生（不要忘了著名的IOS goto失败错误）。因此，我认为这应该是考虑您的代码样式时要考虑的因素（某些工具会警告您误导性缩进，因此它也取决于您的工具链）。

有效代码（看起来像是一个bug）

即使假设您的项目没有遭受此类bug，在阅读代码时，您可能也会看到一些看起来像是bug的代码块-但事实并非如此，循环。

我们从以下内容开始：

if (foo)
    bar();

开发人员添加了有用的注释。

if (foo)
    // At this point we know foo is valid.
    bar();

稍​​后在开发人员上进行扩展。

if (foo)
    // At this point we know foo is valid.
    // This never fails but is too slow even for debug, so keep disabled.
    // assert(is_valid(foo));
    bar();

或添加嵌套块：

if (foo)
    while (i--) {
        bar(i);
        baz(i);
    }

或使用宏：

if (foo)
    SOME_MACRO();

“ ...由于宏可以定义多行代码，因此该宏是否对多行使用do {...} while (0)？它在我们的样式指南中，但我最好还是以防万一！”


上面的示例都是有效的代码，但是代码块中的内容更多，您需要阅读的内容越多，以确保没有任何错误。

也许您的代码风格定义了多行块需要大括号（无论如何，即使它们不是代码） ，但是我已经在生产代码中看到了这些注释。当您阅读它时，会有一个小小的疑问，就是最后编辑这些行的人忘了添加括号，有时我觉得需要仔细检查是否正在按预期的方式工作（尤其是在研究该代码区域的错误时）。 br噪声



在一行中使用括号的一个实际原因是减少diff噪声。

，即更改：

if (foo)
    bar();

收件人：

if (foo) {
    bar();
    baz();
}

...导致条件行在差异中显示为已更改，这会增加一些小但不必要的开销。


这些行会显示就像在代码审查中被更改一样，如果您的差异工具是基于单词的，您可以很容易地看到只有花括号已更改，但这需要花费更多的时间检查行是否根本没有更改。工具支持基于单词的差异，即使使用精美的工具，差异（svn，git，hg等）的显示也会像整行一样显示，有时您可能需要快速查看基于普通行的差异才能查看
注释工具（例如git blame）将显示该行已更改，从而使跟踪行的原点更加容易以找到实际的更改。

它们都很小，并且取决于您在代码审查或跟踪中花费了多少时间来提交更改的代码行。

在diff中增加额外的行更改会带来更明显的不便，它们的可能性更大-hood代码更改将导致合并冲突，需要手动解决。


对此有一个例外，对于单独具有{的代码库-没问题。

如果使用这种样式编写，diff noise参数将不成立：

if (foo)
{
    bar();
    baz();
}

但是这不是如此常见的约定，因此主要增加了完整性的答案（不建议项目使用这种样式）。

#5 楼

多年前，我被带去调试一些C代码。该错误很难被发现，但最终归结为如下语句：

if (debug)
   foo (4);

结果发现，编写该错误的人将foo定义为一个宏。包含两行代码的宏。当然，只有这两行中的第一行受if的约束。 （因此第二行是无条件执行的。）

这对于C及其预处理器可能是绝对唯一的-在编译之前进行替换-但我从未忘记它。那样的事情会在您身上留下印记，为什么不安全地使用它-尤其是如果您使用多种语言和工具链，并且不能确定在其他地方无法实现这种恶作剧吗？

现在显然，我缩进和使用括号的方式与其他所有人不同。对于单行if，我可以这样做：

if (debug) { foo (4); }

，因此不需要任何其他行即可包含括号。

#6 楼

允许“鲍勃叔叔”发表意见，允许您发表意见。无需挑战他。

如果您想上诉权威，请选择克里斯·拉特纳（Chris Lattner）。在Swift中，if语句失去了括号，但始终带有花括号。没有讨论，这是语言的一部分。因此，如果“鲍勃叔叔”开始删除花括号，则代码将停止编译。

检查别人的代码并“摆脱无用的括号”是一个坏习惯。仅在需要检查代码以及不必要地产生冲突时才引起额外的工作。也许“鲍勃叔叔”是如此优秀的程序员，以至于他不需要代码审查？我浪费了一个星期的时间，因为一位顶级程序员在没有代码审查的情况下将“ if（p！= NULL）”更改为“ if（！p）”，这被隐藏在最糟糕的地方。

这主要是一场无害的风格辩论。花括号的优点是您可以插入另一行代码而无需添加花括号。就像日志记录语句或注释（如果后面紧跟注释，则太糟糕了）。在同一行上的语句似乎具有实际的缺点，即许多调试器都存在问题。但是随便你怎么做。

#7 楼

我不删除括号的原因是：


减少决策疲劳。如果您始终使用花括号，则不必决定是否需要花括号。
减少开发负担：即使您最终尝试将所有多行逻辑提取到方法中，也必须将无花括号转换为如果要增加逻辑，这会拖累开发工作。因此，需要删除花括号，并在需要更多代码时再次添加花括号。小而烦人。

#8 楼

一位年轻的同事曾说过，我们认为多余和多余的牙套实际上对他有帮助。我不记得确切的原因，但是如果它能让他更快地编写更好的代码，那仅仅是保留它们的原因。
最后，我们达成了一个妥协，即将它们放在一行上不会令这样简短的前提令我难以理解/分散我的注意力。例如，

if (!param) { throw invalid_argument (blahblah); }
if (n < 2) { return 0; }
// real code for function starts here...

我还指出，这些介绍性前提条件通常是身体的控制流语句（例如return），因此担心添加第二个语句意味着在相同条件下忘记写括号是没有意义的。在这种情况下的第二条语句无论如何都是死代码，没有任何意义。

我怀疑阅读问题的流利性是由于人的大脑解析器被连接成将大括号作为条件条件的一部分而引起的声明。那不是C ++语法的准确表示，但是可能是首先学习某些其他语言的副作用（在这种情况下）。

评论

---

鲍勃叔叔可能认为没有它们，他可以更快地编写更好的代码。

–djechlin
16年6月6日，0：27

---

我和其他人也能熟练使用C ++。

–JDługosz
16年6月6日在4:15

---

“如果它允许他更快地编写更好的代码，那就是保留它们的唯一原因。” ++我有一个小儿子也这么说，因此，我们保留了它们。

–RubberDuck
16年6月6日在11:36

---

...因此，这就是独自按照鲍伯叔叔想要的方式这样做的原因。

–djechlin
16年6月6日在16:05

---

#9 楼

刚刚看完该视频，我注意到消除花括号可以使您更轻松地了解仍需要重构代码的位置。如果需要大括号，您的代码可能会更简洁一些。

已经说过，当您在团队中时，消除大括号可能有一天会导致意外行为。我说保留它们，当事情出错时，您会为自己省下很多头痛。

#10 楼

教我不要执行此操作，因为它可以通过添加另一个缩进的行（如果不是由if
控制的话）来引入一个
错误，这很容易。


如果您的代码已经过良好的单元测试，则这种“ bug”会在脸上爆炸。

我遵循的做法是避免使用任何无用和丑陋的括号来清理代码。