我的一些同事对他们的错误修复使用了特殊的评论，例如：
// 2008-09-23 John Doe - bug 12345
// <short description>
这有意义吗？
您是否以特殊方式评论错误修复？
请告诉我。
koschi
问问题
3283 次
21 回答
34
我没有发表这样的评论，源代码控制系统已经维护了该历史记录，并且我已经能够记录文件的历史记录。
我确实发表了评论，描述了为什么正在做一些不明显的事情。因此，如果错误修复使代码的可预测性和清晰度降低，那么我将解释原因。
于 2008-09-23T21:18:51.453 回答
15
随着时间的推移，这些会累积并增加混乱。最好使代码清晰，为可能不明显的相关问题添加任何注释，并将错误详细信息保留在跟踪系统和存储库中。
于 2008-09-23T21:19:17.867 回答
6
我倾向于不对实际来源发表评论，因为可能很难保持最新状态。但是，我确实将链接评论放在我的源代码控制日志和问题跟踪器中。例如，我可能会在 Perforce 中做这样的事情：
[Bug-Id] xyz 对话框有问题。将尺寸调整代码移至 abc，现在稍后进行初始化。
然后在我的问题跟踪器中，我将执行以下操作：
已在更改列表 1234 中修复。
将尺寸调整代码移至 abc，现在稍后进行初始化。
因为这样就留下了一个很好的历史标记。如果您想知道为什么特定的代码行是某种方式，这也很容易，您只需查看文件历史记录即可。找到代码行后，您可以阅读我的提交评论并清楚地看到它是针对哪个错误以及我如何修复它的。
于 2008-09-23T21:20:07.380 回答
4
只有当解决方案特别聪明或难以理解时。
于 2008-09-23T21:18:04.310 回答
4
我通常会添加我的姓名、电子邮件地址和日期以及我所做更改的简短描述，这是因为作为顾问，我经常修复其他人的代码。
// Glenn F. Henriksen (<email@company.no) - 2008-09-23
// <Short description>
这样，代码所有者或追随我的人就可以弄清楚发生了什么，并且在必要时可以与我联系。
（是的，不幸的是，他们往往没有源代码控制......对于内部的东西我使用 TFS 跟踪）
于 2008-09-23T21:20:24.087 回答
4
虽然这在当时看起来是个好主意，但很快就会失控。使用源代码控制系统和错误跟踪器的良好组合可以更好地捕获此类信息。当然，如果发生了一些棘手的事情，描述情况的注释无论如何都会有帮助，但不是日期、名称或错误编号。
我目前正在工作的代码库已经有 20 年的历史了，他们似乎在几年前添加了很多评论。幸运的是，他们在 90 年代后期将所有东西都转换为 CVS 后几年就停止了。然而，这样的评论仍然散布在整个代码中，现在的政策是“如果你直接处理该代码，则删除它们，否则留下它们”。它们通常很难遵循，特别是如果多次添加和删除相同的代码（是的，它会发生）。它们也不包含日期，但包含你必须在一个古老的系统中查找才能找到日期的错误编号，所以没有人这样做。
于 2008-09-23T21:21:35.973 回答
3
像这样的评论就是为什么 Subversion 允许你在每次提交时输入一个日志条目。那是你应该把这些东西放在哪里，而不是在代码中。
于 2008-09-23T21:18:47.897 回答
2
虽然我确实倾向于在工作代码中看到一些关于错误的评论，但我个人的偏好是将代码提交链接到一个错误。当我说一个时，我的意思是一个错误。之后，您可以随时查看所做的更改并知道这些更改应用于哪个错误。
于 2008-09-23T21:20:00.827 回答
2
如果错误修复涉及不简单的事情，我会这样做，但如果错误修复需要很长的解释，我通常会认为它是修复设计不佳的标志。有时我必须解决一个无法更改的公共接口，因此这往往是这些评论的来源，例如：
// <date> [my name] - Bug xxxxx happens when the foo parameter is null, but
// some customers want the behavior. Jump through some hoops to find a default value.
在其他情况下，源代码控制提交消息是我用来注释更改的。
于 2008-09-23T21:22:04.067 回答
2
这种评论风格在多开发人员环境中非常有价值，在该环境中，开发人员拥有一系列技能和/或业务知识（例如，无处不在）。
对于经验丰富、知识渊博的开发人员来说，更改的原因可能很明显，但对于新开发人员来说，这些评论会让他们三思而后行，在搞砸之前做更多的调查。它还可以帮助他们更多地了解系统的工作原理。
哦，还有一个关于“我只是把它放在源代码控制系统中”的经验注释：
如果它不在源头中，它就不会发生。
由于缺乏源代码控制软件经验、不正确的分支模型等，我无法计算项目源历史记录丢失的次数。只有一个地方不能丢失更改历史记录——那就是在源文件中。
我通常先把它放在那里，然后在我签入时剪切并粘贴相同的评论。
于 2008-09-23T21:22:39.417 回答
1
不，我没有，我讨厌这样的涂鸦乱扔代码。可以在版本控制系统的提交消息中跟踪错误号，并通过脚本将相关的提交消息推送到错误跟踪系统中。我不相信它们属于源代码，未来的编辑只会让事情变得混乱。
于 2008-09-23T21:21:24.740 回答
1
通常，这样的评论更令人困惑，因为您并没有真正了解原始代码的外观或原始不良行为的上下文。
一般来说，如果您的错误修复现在使代码正确运行，只需简单地保留它而不加注释。无需注释正确的代码。
有时错误修复会让事情看起来很奇怪，或者错误修复正在测试不寻常的东西。那么有一个评论可能是合适的——通常评论应该引用你的错误数据库中的“错误编号”。例如，您可能有一条评论说“错误 123 - 用户在 640 x 480 屏幕分辨率下的奇怪行为”。
于 2008-09-23T21:22:37.110 回答
1
如果您在维护代码几年后添加这样的注释，您将拥有如此多的错误修复注释，您将无法阅读代码。
但是如果你把一些看起来正确的东西（但有一个微妙的错误）改成了更复杂的东西，最好添加一个简短的注释来解释你做了什么，这样下一个维护这段代码的程序员就不会因为他把它改回来了（或她）认为你无缘无故地把事情复杂化了。
于 2008-09-23T21:24:04.920 回答
1
不，我使用颠覆，并且总是输入我提交更改的动机的描述。我通常不会用英语重述解决方案，而是总结所做的更改。
我参与过许多项目，他们在修复错误时在代码中添加注释。有趣且可能并非巧合的是，这些项目要么不使用任何类型的源代码控制工具，要么被管理层授权遵循这种约定。
老实说，在大多数情况下，我并没有真正看到这样做的价值。如果我想知道发生了什么变化，我会查看颠覆日志和差异。
只是我的两分钱。
于 2008-09-23T21:31:57.727 回答
1
如果代码被更正了，评论就毫无用处，任何人都不会感兴趣——只是噪音。
如果错误未解决，则注释错误。那么它是有道理的。:) 所以如果你没有真正解决这个错误，就留下这样的评论。
于 2011-02-28T06:09:42.673 回答
0
为了找到特定的评论，我们使用DKBUGBUG - 这意味着 David Kelley 的修复和审阅者可以轻松识别，当然我们将添加日期和其他 VSTS 错误跟踪号等。
于 2008-09-23T21:20:03.853 回答
0
不要复制 VCS 将为您保留的元数据。日期和名称应由 VCS 自动添加。请求更改的票号、经理/用户名等应在 VCS 注释中，而不是代码中。
而不是这样：
//$DATE $NAME $TICKET //对下一个可怜的灵魂有用的评论
我会这样做：
//对下一个可怜的灵魂有用的评论
于 2008-09-23T21:21:53.757 回答
0
如果代码位于实时平台上，而不是直接访问源代码控制存储库，那么我将添加注释以突出显示作为修复实时系统错误的一部分所做的更改。
否则，您在签入时输入的消息不应包含您需要的所有信息。
干杯，
抢
于 2008-09-23T21:27:19.140 回答
0
当我在第三方库/组件中进行错误修复/增强时，我经常会发表一些评论。如果我需要使用更新版本的库/组件，这使查找和移动更改变得更容易。
在我自己的代码中，我很少评论错误修正。
于 2008-09-23T23:26:35.890 回答
0
我不从事多人项目，但有时我会在单元测试中添加有关某个错误的评论。
请记住，没有错误之类的东西，只是测试不足。
于 2010-02-01T05:55:15.973 回答
0
由于我尽可能多地进行 TDD（其他一切都是社交自杀，因为其他所有方法都会迫使您无休止地工作），我很少修复错误。
大多数时候，我会在代码中添加类似这样的特殊注释：
// I KNOW this may look strange to you, but I have to use
// this special implementation here - if you don't understand that,
// maybe you are the wrong person for the job.
听起来很刺耳，但大多数自称“开发人员”的人不值得其他评论。
于 2010-07-14T17:09:29.210 回答