val*_*man 4 .net comments coding-style
我是一家小型金融公司项目的测试员.虽然管理层有时会做出"有趣"的决定,但我正在与之合作的团队似乎足够胜任.由于我通常是开发人员的一部分(这个项目是临时工作),我对项目的代码感兴趣.今天我评论说代码似乎很容易评论(这并不夸张;没有任何代码),并立即被告知这是故意的,"源代码注释是你在大型代码库中最大的敌人".
被聘为低级测试人员并且没有任何开发大型企业系统的实际经验,我认为这种观点并不合适,但我仍然想知道这是否真的是一个普遍接受的事实？
当然,代码应在一个清晰,不言自明的方式尽可能地书写,减少或无需评论个别代码段,但这个项目有意似乎不使用任何意见可言,甚至没有xmlDoc中评论方法和/或类,这对我来说似乎是非常错误的.这是否真的被普遍认同为大型项目的最佳实践？
评论确实会过时,而不正确的评论确实比没有评论更糟糕.同样,如果强制执行的 xml注释往往是如此之小(只是为了使编译器满意),以便添加零值.
然而; 评论到期时评论是好的IMO.我对我的评论非常清楚,但是当我添加评论时,它很重要 - 它可能解释了特定设计选择的原因; 一些需要理解的逻辑的非显而易见的方面; 或者一些粗略的线程问题,随意的读者必须意识到.它可能交叉引用业务规则,错误票据/案例编号,或引用某些外部参考以获取有关主题的更多信息.
所以,我确实同意你的观点(规则)没有任何评论是愚蠢的.但是太多的评论也是愚蠢的(IMO).我希望我的注意力集中在重要的事情上,如果代码淹没在绿色中,我就不能这样做.