}后代码块末尾的“ //…”注释-好还是坏？[关闭]

我经常看到这样的评论：

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

有时甚至

if (condition) {
   ...
} // if (condition)

我从不了解这种做法，因此也从未应用过。如果您的代码很长，以至于您需要知道结尾}是什么，那么也许您应该考虑将其拆分为单独的函数。而且，大多数开发人员工具都可以跳转到相应的括号。最后，对我来说，最后一个明显违反了DRY原则；如果您更改条件，则必须记住也要更改注释（否则可能会使维护者甚至您变得混乱）。

那么人们为什么要使用它呢？我们应该使用它，还是不好的做法？

我要说的是，如果您的代码太长，以致于您无法轻松地遵循括号，那么对于大多数语言而言，您的代码就需要重构。

但是，在模板语言（如PHP）中，它可能是有效的，因为您可能有大量的HTML块将条件或循环结构的开始和结束分开。

这是一种代码气味，通常是老式代码风格的宿醉。之前，体面的IDE重构变得更加困难且不像现在那样普遍，因此方法更长了，这些注释可以帮助他们更好地导航。

这是一种由于许多因素而过时的可怕做法。

• 当插入符号在任一符号上时，大多数现代IDE都会突出显示相应的括号。
• 如果您编写的代码整洁，则很少会找到方法超过10行的地方。

我注意到许多Java程序员都具有这种思维方式，这使Java代码看起来确实很脏，并且将注意力从代码转移到了注释上。

强烈建议不要使用此功能。

读取的代码比编写的代码多10倍。

如果它更易于阅读，请执行此操作。

我也建议任何这样做的人，他们应该考虑其他一些使事情更容易阅读的方法。别人提到的重构技术，不同行上的括号等都很好。将事物拆分为不同的函数，方法或类，以便代码可以自我注释也很好。还有一些方法可以消除大多数“ if”并将“ for”循环放入明显的​​位置，从而消除了对任何这种情况的需要。

但是，有时人们正在学习。如果这是他们正在做的事情，那实际上是在使代码更具可读性，鼓励它，然后再鼓励其他一些实践。学习的人们应该得到鼓励，无论他们如何开始，都将从中受益。说“这不好”不如说“这更好”。

我有一个很大的（C ++）代码库，里面充满了这种东西：

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

对于这么小的东西，我会说这超出了“代码气味”到“代码臭味”的范围。尤其是在IDE中，我可以通过按键将右括号与右括号匹配以找到右括号。给定更长的方法，我仍然会在终端注释上进行括号匹配。这样的评论分散了我的注意力，我倾向于将它们视为噪音。

在C ++中，有两个保持有效的保持状态，不需要“拆分代码”的建议保持有效：

1. 对于名称空间。名称空间可以包含整个文件，并且最后一个括号有时可能会使人丢掉，因此添加注释以指示括号是名称空间的关闭很有用。对于我公司的特定编码风格而言，这很重要，因为我们不缩进名称空间，因为我们决定缩进只会浪费文件中的空间。

2. 适用于#ifdef / #endif对。有时，其中有很多代码用于条件编译，嵌套时可能会令人讨厌，并且我们经常使用的编辑器“费力地”消除了缩进，因此注释在快速概述中很有用。

对我来说，代码必须令人困惑，难以添加您指定的注释。

如果只是说// IF语句。然后您想知道为什么它首先存在。

看到大括号正在关闭的另一种方法是在与关闭列相同的列上放置一个打开。我发现它更清晰，更易读。

当由于打开很久以前而通常难以跟踪时，该注释很有用。通常只对名称空间（特别是C ++中的匿名名称空间，用于编译单元中的实现细节）才发生这种情况。在大多数其他情况下，很明显您要关闭的内容。

这很大程度上是对80x24字符终端窗口中过去工作的保留，特别是如果您使用的是EVE之类的窗口式编辑器。即使现在，我还是在使用vim的终端会话中完成大部分工作，并且可以将会话拆分为三个或四个子窗口，因此我实际上只能在任何时间查看几行。

话虽如此，但我从来没有真正热衷于这项公约，即使它可以不止一次地挽救我的培根。我只是将其视为噪音。是的，如果循环或条件变得如此庞大，那么您可能要考虑重构。

您基本上会给出所有不使用此功能的正当理由。每个体面的程序员都应该应用这些。那么，为什么做的人使用它？因为他们做错了，而且并不了解。