什么时候应该避免注释代码

看到标题，我知道你可能会想：“我为什么要避免代码注释，这难道不是一件好事吗？”。是的，写注释在大多数情况下是有用的。但是，请注意，我说的是“在大多数情况下”，因为有一些情况下，你不应该写注释。

建网站原本是网站策划师、网络程序员、网页设计师等，应用各种网络程序开发技术和网页设计技术配合操作的协同工作。成都创新互联专业提供成都做网站、网站建设,网页设计,网站制作(企业站、自适应网站建设、电商门户网站)等服务,从网站深度策划、搜索引擎友好度优化到用户体验的提升,我们力求做到极致!

还不相信？那让我告诉你：写注释有时会坏事！会导致坏代码！

请允许我用一句名言来开始我的论证：不要注释坏代码——重写吧。——Brian W. Kernighan and P. J. Plaugher

这句话给我流下了非常深刻的印象。仔细想一想，有多少次你注释你的代码，只是因为担心自己将来再回过头来阅读的时候可能会不理解它的意思？至少都做过一次吧。坦率地说，我有很多次是因为这个原因才注释的，尤其是在那些我还是重构和编写干净代码的新手的日子里。

那么，为什么这样的注释反而不好呢？简而言之是因为，我们会因为有注释而放任编写坏的代码！正如你所看到的，注释有时候反而激励了我们去写一些不整洁的代码。

另一个原因是因为注释会误导我们。有多少次你已经改变了代码，却忘了改旁边的注释？别否认，这种事时常发生。这就是为什么你经常听到这样一句话，“真理只存在于代码中”。

那么，什么时候你不应该写注释呢？

有一个经验法则就是，无论何时你发现自己要使用注释来解释这段代码是用来干什么的时候，那么基本上就是你的代码需要重构以变得更整洁的时候。

典型的解决方案

现在你知道为什么有时候反而要避免写注释了，那么有什么解决办法吗。事实上，目前还没有一个有效的解决方案，但是你可以清洁你的代码，这样你（以及其他人）就可以在没有注释的情况下也能理解它了。

为了用可读的代码替换掉注释，通常我们的典型解决方法是使用提取方法重构（Extract Method refactoring）。这种重构方式是我最喜欢的。对此我也写过一篇博客，里面有完整的例子：《Break Your Method Into Smaller Ones》。

下面让我们看一个简单说明如何提高你的代码，从而解放注释的例子。

isPremium() and $customer->numberOfPurchases > 8) {

}

// OR

if ($customer->canGetFreeProduct()) {

}

我希望你能注意到这两个条件语句之间的差异。哪一个更整洁？很明显第二个更整洁，更好。这是因为，首先，可以删除注释，因为我们看代码就明白了意思。其次，也是最重要的一点是，我们提取了检查客户是否值得获得免费产品的逻辑到它的方法中，这是一件好事，特别是当你想要在应用程序中再次使用它的话。

对于更详细的例子，我推荐你阅读我以前发表过的文章。

结论

请允许我用一个免责说明来结束这篇文章。我不反对注释。注释在大多数情况下是非常有用的，尤其是在开源项目中。

我想说的是，你不应该为你的坏代码注释。请记住，“真理只存在于代码中”。

译文链接：
http://www.codeceo.com/article/when-avoid-comment-code.html

英文原文：When Should You Avoid Commenting Your Code?

新闻名称：什么时候应该避免注释代码
当前链接：http://www.36103.cn/qtweb/news49/5449.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联