的Bug数量评论
你为什么要添加的Bug数量评论
//错误1024
注释到源控制的代码库？ 大多数的错误跟踪和源代码管理系统都能更好地跟踪这些信息。 在源代码控制中，标签或注释可以与签入一起使用。在错误跟踪器中，可以将修订号添加到错误的分辨率中。那么为什么要评论代码？特别是因为这些评论相关性非常短暂，他们倾向于积累乱抛垃圾的代码库。
我发现其中一个在我们的代码库有用的那天。
我说“为什么他第二次调用初始化函数，这在工作流的最后阶段??”
该错误评论让我去正确的问题描述。当我重新编写代码时，我肯定会将该错误包含在我的测试中，而不是重新引入它。
虽然我会说，一般来说，我同意你的观点，不要自己插入。
我更希望有问题的开发人员以更有意义的方式修复了这个错误，这样我就不必首先想到代码了。
纯粹的懒惰。当然，从长远来看需要更多时间，但在短期内“// Bug 1024”无论如何都不费吹灰之力。你拥有的代码越多，这就越糟糕。
最终，我认为这是一个不好的做法。最好包括错误存在的原因（类型Y的fo不具有属性Z）。如果需要，可以在“BugId 12345”中加入“更多内容”。
如果您在多个级别上进行集成，trac中的源代码视图可以直接链接到BugId。
我这样做直到Visual Studio 2008附带注释。当回顾旧代码时，立即看到至少有一个特定的代码决策背后有过思考，这很有用。
是的，我知道你可以和以前的版本做比较，但是如果你只需要一些简短的代码更新的快速感受，就会感到很痛苦。
想象一下，您有一个新的错误，可以追溯到修订版12345中的更改。您查看日志，它会立即告诉您Bug 1024是进行更改的原因。
然后，您可以去看看1024年，看看在做出新修正之前是什么，为什么以及什么时候 - “统治所有人”。
如果错误编号不在提交消息中，那么您必须搜索提交修复的错误 - 这可能是几个错误（如果错误报告不止一次）。
我同意你的看法，这不是真的有用，而且太简短了。
然而，它是非常有用和重要的，以引用缺陷跟踪系统中的记录（或扩展到您可能拥有的任何知识库）来评论代码。
有时一个代码更改实施规避一定的问题与应用程序的行为。有时候，引入的解决方法绝不合逻辑。经常发生的情况是，当代码被其他人更新时，这个“坏”的代码片段被作为重新分解工作的一部分被移除。
所以，标志着代码属于特定漏洞修复，使再保期间，可见，促使开发商改变代码之前查看错误描述。它还有助于在错误重新打开的情况下 - 如果您不得不多次更改代码的相同部分，您可能会考虑将时间投入到替代解决方案中。
P.S.你可以考虑从Joel On Software的关于MS Office的文章this。据我所知，MS Office和MS Windows的代码充满了类似的评论，这些评论解释了开发者早已离开的决定。
我觉得它有用解释代码，否则似乎错的时候，也用在提交信息。
如果通过不熟悉的源代码浏览，和你看到的东西不明显，这是很好的知道原因。这是一个判断电话，但并非每一个错误修复都需要这样的解释 - 如果没有它，大多数情况下都可能逃脱。
我认为这是一个“我有锤子，一定是钉子”的情况。您的文本编辑器或IDE不是管理代码的唯一工具。
历史最好在代码的外部维护。代码的含义应该在注释中描述，但不能立即显现。
我同意bug数应该在源控制提交消息中。
我不这样做。我想不出为什么你会在代码中放入缺陷ID。我将把它放在发行说明/更新日志上。
我真正有用的是使用缺陷ID作为自动化测试的名称的一部分：
[TestFixture]
public class Release_1_2_Bugfixes
{
[Test]
public void TestBug42()
{
Assert.AreEqual(42, CalculateAnswerToLifeUniverseAndEverything());
}
}
我见过other projects做同样的事情。
如果有足够的理由相信有人想在查看部分代码时想知道错误号，那么添加一个提及该错误的注释可能会相当不错（希望它能够解释错误的重要部分）但是）。
是的，源代码控制提交信息中还应该包含错误号码，并期待通过修改日志可以给你同样的信息......但如果代码的同一部分被多次更改，但在细节上了解到，从最初的错误仍然适用，可能需要一段时间才能找到原始更改以了解该错误。
此外，当有充分的理由将代码从一个类移动到另一个类或重命名文件时会出现这种情况，这会使得更难找到某段代码背后原因的根源（不重命名如此多的SVN问题，但与CVS的痛苦）。
你不应该只添加错误号。您应该添加的bug数量和对象，以及任何限定词，如果你做了一个错误多签：
错误1111 - 美孚捣毁的64位系统。修复＃2，因为它在合并到主干后重新打开。
某些系统具有错误号集成。在mxr.mozilla.org中，CVS日志显示中的错误编号会自动变成链接到bugzilla.mozilla.org编号的链接。当你在代码中挖掘，这是一个巨大的时间段。我认为Fogbugz有一个类似的功能...
另外，即使你的系统没有，它通常也是有帮助的，因为没有人想看到整个上下文的变化，这就是bug追踪器的用处。
你碰到了一个问题：“相关性非常短暂，他们倾向于积累垃圾代码库。”
构建在源文件中的每一点无用信号都使得它们不易读，难以维护。删除没有增加价值的所有内容。 “Bug 12345”现在几乎没什么价值，几周后就没有了。
我们在一个大型系统上工作，有许多开发人员和多个分支机构。
这些错误引用注释在从一个分支移植到另一个分支时实际上非常有用，特别是因为我们使用的SCM系统功能很差，提交注释很难获得或可能会很老。
如果修复很简单，那么它可能不需要错误标记。如果它不明显，那么引用一个Bug可能更有意义，然后在评论部分写一个长的解释。
我不喜欢这种涂鸦。像其他不合时宜的生活形式一样，它们随着时间的流逝而增加，窒息了代码库。
当人们进行错误修复时，麻烦真的开始了，这些错误修复重叠了以前的错误修复。然后你有bug编号标记了一段简单的错误或误导的代码。
我很惊讶有多少人反对这一点。我个人对此的感觉是，这是一个很好的想法想法。我同意早先的评论，它应该不仅包括错误编号，并且最好包括一个简短的摘要和链接到错误跟踪系统（如果适用的话）。
这些评论的好处只在具有历史记录和大量以前的错误修复的较旧项目中显而易见。您无需在任何地方发表这些评论，但是将它们放置在可能没有上下文无关的代码块之前时非常有用。在任何一种相当复杂的系统中，都会出现代码片段，这些代码在没有上下文的情况下似乎不合逻辑或不必要。
由于与系统或旧的解决方法的交互，代码是必要的。为了防止某个人稍后重新引入补丁错误，指出代码块旨在修复的错误非常有用，最好附带一些类型的解释。否则，你会依赖于某人在提交日志中仔细检查提交历史记录的原因，这是非常不可能的，特别是如果某人正在重构代码。
编辑：我特指将这些代码与不寻常的代码块或需要额外的上下文。对你所做的每一个错字修改都没有意见或建议:-)
这种类型的评论IS非常有帮助：当你改变错误跟踪或源代码控制工具时会发生什么？对BZ1722与FB3101的引用会告诉你需要检查的跟踪工具（例如Bugzilla或FogBugz）。
这是一件好事！
谁在看代码的人是不可能体会到代码的完整历史，并有可能撤销一个非常重要的变化，因为他们可能没有这方面的代码的工作之前。它可以解释代码，否则看起来疯狂或客户的要求相当离奇。
你不能总是通过架构和代码捕捉客户需求的具体的，特定，尤其是当他们问一些愚蠢的事。因此，你开始懂事，然后提炼或代码攻入愚蠢时，你不得不这样做，这个bug数备份疯狂代码的意图。
有一个类似的问题问早前：http://*.com/questions/123936/do-you-use-special-comments-on-bug-fixes-in-your-code – DGentry 2008-10-02 17:18:53
我一直在寻找这种行为背后的理性，前一个问题似乎没有涉及。它有点过于宽泛。 – 2008-10-02 17:29:28