关于关闭 {} 的 C# 注释
我一直在使用 DevExpress CodeRush 和 Refactor！ Pro 这周，我选择了一个注释器插件，它会在您键入代码时自动生成注释。
我不想讨论它在挑选基本含义方面做得有多好（实际上非常好），但它的默认实现确实提出了一个问题。
默认情况下，输入 } 字符来关闭块将导致插件添加如下注释...
using(MyType myType = new MyType())
{
myType.doWork();
} // using
（即在打开它的右大括号标签中添加注释。）
虽然我可以看到在某些情况下这种行为可能很有用，我觉得由于所有附加注释，最终的代码看起来非常凌乱。
我想知道其他人对这种评论有何看法。 不仅仅是从学术的角度来看，如果我收到大量关于它们的负面评论，我可以决定是把它们强加给我的同事还是把它们开除。
I've been working a little with DevExpress CodeRush and Refactor! Pro this week, and I picked up a commentor plug-in that will automatically generate comments as you type code.
I don't want to go into how good a job it does of picking out basic meaning (pretty good, actually) but it's default implementation does raise a question.
By default, typing a } character to close a block will result in the plugin adding a comment like the following...
using(MyType myType = new MyType())
{
myType.doWork();
} // using
(i.e. adding a comment to the closing brace labelling where it was opened.)
While I can see that there are instances where this behaviour may be of great use, I feel that the resultant code looks very untidy with all the additional commenting.
I was wondering what other people;'s take on this kind of comment was. Not just from an academic standpoint, but if I get a good number of negative comments about them I can decide whether to inflict them upon my co-workers or strip them out.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
我认为这样的评论是没有用的，除非代码很糟糕。 通过正确的代码格式，不难看出块在哪里开始和在哪里结束，因为通常这些块是缩进的。
编辑：
如果一个过程太大以至于不太明显哪个代码块被大括号封闭，那么无论如何应该已经有更多描述性注释来描述该过程，并且这些注释只会变得混乱。
I think comments like that are useless, unless of course the code is awful. With proper formatting of code it's not difficult to see where a block starts and where a block ends because usually those blocks are indented.
Edit:
If a procedure is so big that is not readily apparent what block of code is being closed by a brace, then there should already be more descriptive comments describing the procedure anyways and these comments would just be clutter.
我发现从代码生成注释的插件的想法相当无用。 如果机器可以推断出它，那么任何阅读它的人也可以推断出它。 这些评论极有可能是完全多余的。
我觉得那些右大括号注释很混乱，如果个人需要的话，它提供的信息最好直接由 IDE 提供。
I find the idea of a plugin that genrates comments from code rather useless. If it can be inferred by the machine then it can also be inferred by anybody reading it. The comments are extremely likely to be totally redundant.
I feel that those closing brace comment is messy, it gives information that is better provided directly by the IDE if the individual wants it.
IMO 每一条描述代码已经告诉你的内容的注释都是不必要的。
如果您确实有很长的代码块，以至于您必须滚动很多次才能看到开头，那么您就做错了一些事情，并且可以考虑将代码拆分。
IMO every comment that is describing what the code is already telling you is unnecessary.
If you really have code blocks that are so long that you have to scroll a lot to see there beginning you have done something wrong and may consider to split the code up.
糟糕的评论风格 - 它在代码库中引入了维护开销。
我知道前 VB 程序员发现 C 语法代码中的
}令人困惑，但在这种情况下，真正的解决方法是重构代码以防止深层嵌套和过长的函数和/或代码块。Bad bad comment style - it introduces a maintainance overhead in the codebase.
I've known ex-VB coders who found trails of
}s in C-syntax code to be confusing, but in this scenario the real fix is to refactor your code to prevent deep nesting and excessively long functions and/or code blocks.如果 using 块扩展到 IDE 中的一个页面，那么这可能很有用，但是您还有其他问题需要担心。 在这种情况下，我通过适当的缩进和一个 IDE 在我选择一个大括号时突出显示匹配的大括号。
总的来说，我对它持反对态度，但当你无法避免长块时，它有潜在的用途。
Maybe useful if the using block extends over a page in the IDE, but then you've got other problems to worry about. In this case I get by with proper indenting and an IDE that highlights the matching brace when I select one.
I give it a thumbs down in general, but with potential use when you can't avoid a long block otherwise.
有时你会得到非常大的代码块，或者很多嵌套的块闭合在一起。 我有时会在这种情况下使用这种风格，但绝对不是一直如此。 我也不将其限制为代码：HTML 可以从这种“密切注释”风格中受益匪浅：
Sometimes you will get very large code blocks, or a lot of nested blocks closing together. I sometimes use this style in cases like this, but definitely not all the time. I don't restrict it to code either: HTML can benefit greatly from this style of "close commenting":
这种注释仅对具有许多嵌套块的很长的代码块有用。 但这就是说，首先不应该是这种情况，因为许多嵌套块和长方法需要重构。
所以我一点也不喜欢这个，因为读者显然可以看到它是什么代码块。
This sort of comments are only usefull on very long blocks of code where you have many nested blocks. But that said this should not be the case in the first place as many nested blocks and long methods call for refactoring.
So I don't like this at all, as the reader obviously can see what block of code it is.
我认为比注释更有用的是 IDE 功能，它不仅可以突出显示匹配的大括号对，还可以在工具提示上显示开头行，这样，如果您将鼠标悬停在示例中的右大括号上，它会显示“using(工具提示中的 MyType myType = new MyType())”。
这将使您能够轻松理解大型函数的复杂嵌套大括号，而不会造成持续的视觉混乱。
I think more useful than comments would be an IDE feature to not only highlight matching pairs of braces, but also display the openining line on a tooltip, so that if you hovered over the closing brace in your example it would come up with "using(MyType myType = new MyType())" in a tooltip.
This would enable you to easily make sense of complex nested braces for large functions without providing constant visual clutter.
我总是发现记住这一点很有用...
清晰、编写良好的代码将为有能力的程序员提供足够的解释代码的用途，以便有能力的程序员能够掌握它。
应该在代码中留下注释来解释为什么代码这样做！
换句话说，使用注释来帮助代码的读者理解算法，或者代码应该实现什么，而不是如何实现它！
您可能想查看 Jeff Atwood 的这篇文章。
I always find it useful to remember this...
Clear, well written code will provide enough of an explanation of what the code is doing for a competent programmer to pick it up.
Comments should be left in the code to explain why the code is doing it!
In other words, use comments to help the reader of your code understand the algorithm, or what the code is supposed to achieve, not how it's achieving it!
You might want to check out this post by Jeff Atwood.
不要这样做，如果到处使用它只会增加噪音，而且正确的缩进应该解决可读性问题。
Don't do it, it simply adds noise if used all over the place, and besides proper indentation should solve the readability problem.
我会把它关掉。 当你有多个块在同一个地方结束（更长或更短的块）时，我只看到使用它的一点 - 我自己在类似这样的情况下使用过它们。 但是，如果使用它们，最好在精心选择的位置手动添加它们，而不是使用一些自动化工具添加它们。
I would keep it turned off. I only see a point in using this when you have multiple blocks ending in the same place (longer or shorter blocks) - I've used them myself in some cases like these. However if they are used it would be better to add them manually, in carefully selected places rather than having some automated tool adding them.
如果您必须考虑某种类型的评论是否可用，那么很可能是后者。
注释用于解释某些代码块或整个实体，以方便理解； 不是为了使格式更易于阅读。
让一个插件总是符合这种行为既臃肿又丑陋。
If you have to consider whether or not a certain type of comment is usable or not, it's most likely the latter.
Comments are for explaining certain blocks of code or an entity in its whole, to ease up on comprehension; not to make the formatting easier to read.
Having a plugin always conform to this behaviour is both obese and ugly.
我同意有更好的方法来描述代码的作用。
如果您有一长段代码，前面有一条信息性注释，例如
// 修复工作项，您可以采用该代码并将其重构为自己的方法。 然后使用注释作为新方法的名称 FixWorkItem()。 这样做是一种使您的代码更加自我记录的快速方法，甚至可能揭示一些您以前没有注意到的设计特征。
请留意诸如潜在重构之类的单行注释，这些注释可以由 IDE 自动处理。 记录自身的代码甚至比写得最好的独立注释更好，当然，描述意图时除外。
I agree there are much better ways to describe what a code is doing.
If you have a long body of code preceded by a single informative comment like
// Fix Work Item, you could take that code and refactor it as its own method. Then use the comment as the new method's name, FixWorkItem(). Doing this is a quick way to make your code more self-documenting and might even reveal some design characteristics you didn't notice before.
Keep an eye out for one-liner comments like that as potential refactors, which can be handled automatically by the IDE. Code that documents itself is better than even the best-written standalone comments, except of course when describing intent.