看到标题，我知道你可能会想：“我为什么要避免代码注释，这不是好事吗？”。是的，在大多数情况下写评论很有用。但是请注意，我说“在大多数情况下”是因为在某些情况下您不应该写评论。还是不相信？那么让我告诉你：写评论有时会很糟糕！会导致错误的代码！请允许我以一句名言开始我的论点：不要评论糟糕的代码——重写它。——BrianW.Kernighan和P.J.Plaugher这句话给我留下了非常深刻的印象。想一想，有多少次你注释掉你的代码，就是因为你担心以后回头看的时候，可能看不懂它的意思？至少做过一次。坦率地说，出于这个原因我已经评论过很多次了，尤其是在我刚接触重构和编写干净代码的那些日子里。那么为什么这样的评论不好呢？简而言之，因为，我们让糟糕的代码因为我们有注释而被编写出来！如您所见，注释有时会促使我们编写不整洁的代码。另一个原因是注释会误导我们。有多少次你改了代码却忘了改旁边的注释？不要否认，它一直在发生。这就是为什么您经常听到这样的说法：“真相只存在于代码中”。那么，什么时候不应该写评论呢？一条经验法则是，每当您发现自己使用注释来解释一段代码的作用时，基本上就是您的代码需要重构以使其更清晰的时候。典型解决方案知道了为什么有时要避免写注释，那么有什么解决方案吗？事实上，目前还没有一个可行的解决方案，但您可以清理代码，这样您（和其他人）就可以在没有注释的情况下理解它。为了用可读的代码替换注释，我们典型的解决方案是使用ExtractMethod重构。这种重构方式是我最喜欢的。我也写了一篇关于这个的博客，里面有一个完整的例子：《Break Your Method Into Smaller Ones》。让我们看一个示例，它简单地展示了如何改进代码以释放注释。isPremium()and$customer->numberOfPurchases>8){}//ORif($customer->canGetFreeProduct()){}我希望您会注意到这两个条件语句之间的区别。哪个更整洁？显然第二个更整洁更好。这是因为，首先，注释是可以去掉的，因为我们看代码就能明白意思。其次，也是最重要的，我们将检查客户是否值得免费产品的逻辑提取到它的方法中，这是一件好事，特别是如果您想在应用程序中再次使用它。有关更详细的示例，我建议您阅读我以前发表的文章。结论请允许我以免责声明结束本文。我不反对注释。注释在大多数情况下非常有用，尤其是在开源项目中。我想说的是你不应该注释你的错误代码。请记住，“真相只存在于代码中”。翻译链接：http://www.codeceo.com/article/when-avoid-comment-code.html英文原文：WhenShouldYouAvoidCommentingYourCode?
