上述代码中的三段注释确实加速了阅读代码的速度， 但每当代码需要注释才能读懂时就应该警醒：是不是结构设计有问题。 对于上述代码，我们可以通过更加可复用的结构来消除注释：
function calcTotalCharge(movies, user){ return calcMovieCharge(movies) + calcUserCharge(user); } function calcMovieCharge(movies){ var total = 0; for(var i=0; i<movies.length; i++){ total += calcSingleMovieCharge(movie); } return total; } function calcSingleMovieCharge(movie){ if(movie.type === 'discount') return movie.charge * 0.8; else if(movie.type === 'short') return movie.charge * 2; else if(movie.type === 'normal') return movie.charge; return 0; } function calcUserCharge(user){ if(user.isVIP1) return 10; else if(user.isVIP2) return 200; else if(user.isVIP3) return 300; else if(user.isVIP4) return 500; return 0; }
代码重构之后原来的注释就变得毫无意义，代码意图都被清晰的表述在标识符的命名中。 通常重构会带来代码量的减小，因为封装了分支、每个单元的逻辑也更加明确。
【建议】：当我们发现不得不进行注释时，需要警醒是否结构设计发生了问题。
有用的注释
至此Harttle已描述了这么多反模式，并非为了说明代码注释不重要。 而是为了说明『代码注释存在的意义在于帮助理解代码本身』。 例如在编写一些Trick，Polyfill，临时代码，以及复杂算法时，注释变得相当重要。 例如：
Tricks and Polyfills。有时简单的Trick就可解决多数问题问题， 为没必要编写复杂的普适算法， 例如检测浏览器的DOM API支持，检测AMD/CommonJS环境等等。 这时我们需要清晰地说明这些Trick的意图，甚至可以将这些代码抽离为polyfill模块。
复杂算法。有时我们会编写数学性非常强的算法，一眼望去不知所云。 在开始这些算法前清晰地说明其意图何在，读者也就不必花大功夫读懂这些数学了。
公有接口。模块的对外接口从逻辑上定义了模块类型，公有接口代码也更容易被人读到。 尤其是JavaScript接口：如果不注释options中到底是什么，谁晓得接口如何使用。