Answers:
通常，我认为这不是好习惯。但是在特殊情况下，它可能非常有用，即当代码必须做一些不直观的操作来解决一个复杂的问题时，如果不做任何解释，就有可能有人要“修复”这个奇怪的代码，从而破坏它。 ，而在解释其原因时会产生巨大的评论，该评论会重复发布该问题中的信息。
我认为在将相关修订提交到源代码管理系统时，只需将问题编号添加到提交消息中即可。
例如：
错误＃203：数据库连接在30秒后不再超时。
我发现添加问题编号，开发人员名称或代码中已进行更改的日期只会污染代码库，实际上应该由源代码控制系统在外部进行管理。
我完全不同意这里的其他海报！
带有跟踪引用的代码注释可以为维护编程提供巨大帮助。
如果我正在跟踪错误并接近代码区域，看到它最近已被更改并链接到更改的上下文是天赐之物。
是的，我们有源代码控制，但是单独检查文件和模块可能会很慢。您希望这些事情对您有所帮助，以便进行最近的更改。
我可能会不赞成使用它们，因为我在代码库中看到的确实是很旧的，但是保留较新的东西几乎没有什么弊端，如果您聪明地使用它们，可能会节省很多开发人员的时间。
我实际上认为这些对您的错误跟踪系统的小引用比代码中的详细注释更可取。
git gui blame <filename>如果使用git ，默认值提供了非常快速的GUI来浏览代码历史记录。使用工具将代码注释与历史结合起来，可以提供比任何内联注释都更好的代码文档。也就是说，如果您不愿意去写好的提交消息（好的提交消息应该与解释为什么要应用此补丁程序的电子邮件大致相等）。
如果您订阅“清洁代码”的政策，那么您可能需要问自己是否添加注释完全是一种好习惯。如果只能用注释来澄清代码，那么可以肯定地添加一个，否则您应该能够简单地通过阅读代码来轻松理解代码的作用（假设您对变量，方法等使用了明智的名称）。
不管您对评论是否是一种好的做法都持个人看法，评论应包含对评论所引用的代码具有直接价值的信息。在这种情况下，问题是添加发行编号是否会增加代码的价值。我看到的添加问题编号的问题是，您可以对一段代码进行修改，以便满足多个问题；过一会儿，可能无法正确识别与特定问题相关的更改。例如，后续问题可能需要对与先前问题相关的代码进行大量重构。这也许是一个极端的例子，但是它确实显示了代码注释中的问题编号可能变得毫无用处。
如果您可以保证我刚才描述的情况永远不会发生，那么我仍然认为，问题编号本身在没有描述问题的实质的情况下仍然毫无用处，但是，所有这些信息确实属于您问题跟踪系统，应该进行重复。记录问题编号的更好位置是在版本控制系统中作为提交注释。优点是，您可以比较版本并查看与特定问题相关的代码更改，而如果您要查看代码更改的原因，则问题编号本身为您提供了所需的标识符。
考虑到所有这些，我建议这不是真正的好习惯，因为在代码中的注释中添加问题编号。
我认为这是一个很好的做法，请参考问题以进一步阅读，同时在注释本身中进行简短说明。
我通常只在该段代码中有些微妙或不直观的地方添加注释。由于一些细微的问题无法在几行中完全解释，并且我不想添加数十行评论，因此我会添加一条简短的评论，以描述这是要实现的目标，并参考该问题以获取更多信息。细节。
例如：
// Verify MAC before checking the padding, to avoid padding oracle attacks
// See issue 123 for details
问题123的内容描述了这种攻击的外观，以及为什么新代码不受攻击。
要么：
// Using foo's algorithm here, since it fits out usage pattern best
// Check issue 345 for a discussion of possible algorithms, and why foo was chosen.
将问题编号放入来源中的主要问题是您现在有一个外部参考。因此，您需要确保不会丢失该问题。