我在一家小型金融公司的一个项目中担任测试员。虽然管理层有时会做出“有趣”的决定，但与我一起工作的团队似乎足够胜任。由于我通常是等式的开发人员部分(这个项目是一个临时工作)，我对项目的代码很感兴趣。今天我评论说代码中的注释似乎很轻(这并不夸张；没有任何注释)，并立即被告知这是故意的，并且“源代码注释是大型代码库中最大的敌人”。
被聘为一名低级测试人员并且没有任何开发大型企业系统的实际经验，我认为不适合质疑这种情绪，但我仍然想知道这是否真的是一个普遍接受的事实？
当然，代码应该尽可能以清晰、不言自明的方式编写，减少或消除对单个代码片段进行注释的需要，但是这个项目似乎根本不使用任何注释，甚至不使用 xmldoc 注释方法和/或类，这对我来说似乎是错误的。这真的被普遍认为是大型项目的最佳实践吗？
最佳答案
评论确实会过时，错误的评论确实比没有评论更糟糕。同样，如果强制执行 xml 注释，则往往很少(只是为了让编译器满意)以致添加零值。
然而;评论到期时发表评论很好 IMO。我对我的评论很轻描淡写，但是当我添加评论时它很重要 - 它可能解释了特定设计选择的原因；需要理解的逻辑的一些不明显的方面；或一些粗略的线程问题，休闲读者必须注意。它可能会交叉引用业务规则、错误单/案例编号，或引用一些外部引用以获取有关某个主题的更多信息。
所以确实，我同意你的意见，没有评论(按规则)是愚蠢的。但是太多的评论也是愚蠢的(IMO)。我希望我的注意力集中在重要的事情上，如果代码淹没在绿色中，我就无法做到这一点。
关于.net - 在大型 .NET 代码库中，评论真的被普遍认为是邪恶的吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6923020/