13518219792
网站建设资讯

NEWS

网站建设资讯

JavaScript中使用代码注释的注意事项

这篇文章主要介绍了JavaScript中使用代码注释的注意事项，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

公司主营业务：网站建设、成都网站制作、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联推出寿宁免费做网站回馈大家。

自动生成的注释

代码注释的泛滥想必是从Eclipse，Visual Studio等IDE开始的。 这些IDE提供了很多快捷功能，生成类/接口的骨架，具有Getter/Setter的属性等等。 如果用过IDE，下面的代码你一定不会陌生：

/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
}

上述6行代码中的4行注释包含的信息量是0，既没有阐释参数args是何物，也没有说明main的用途。 然而大量的项目中都充斥着这样的自动生成注释。

『建议』：如果有参数或机制需要说明，请补充这些信息。否则请删除自动生成注释。 当然，用于生成文档的注释除外。

过多的注释

总会有人不厌其烦地编写长篇累牍的注释，或无微不至，或语焉不详，或晦涩难懂，或文采飞扬。 总之没有帮助我更快阅读代码的注释都是失败的注释。

为了说明问题，Harttle克隆了4.x Linux Kernel源码， 来大致分析一下其注释行数。 我们知道内核代码95%以上是C语言，所以统计.c文件就足够说明问题了。

➜ linux git:(master) git clone git@github.com:torvalds/linux.git --depth=1
➜ linux git:(master) find . -name "*.c" -o -name "*.h" -exec grep -E '^\s*((\*)|(/[/*]))' {} \; | wc -l
724804
➜ linux git:(master) find . -name "*.c" -o -name "*.h" -exec cat {} \; | wc -l
4018961
➜ linux git:(master) node
> 724804/(4018961-724804)
0.22002715717556875

内核仓库中的代码大概是402万行（未移除空行），其中注释72万行，占比22%。 Linux内核使用低级的C语言编写，涉及到复杂的CPU调度、内存管理，驱动程序。 因此注释会偏多一些，一般的项目注释应小于这个数值。

『建议』：如果你的代码中注释超过了20%，那么显然你过度注释了。

文件头注释

很多编辑器/IDE都会生成默认的文件头，例如：

/**
* @file /tmp/xxx.js
* @author harttle(yangjvn@126.com)
* @date 2016-08-30 22:33
* @description A XXX Implementation for XXX.
*/

文件头注释清晰地列出了文件的作者、功能描述等信息，看起来很有用。 不过这样的文件头存在的问题在于其维护性：

  • 其他人做小的修改时未必会修改@author，甚至连@author都不知道现在该文件已经面目全非。

  • 每次移动该文件，是否还需要花功夫更新 @file 信息？

  • 谁会在每次代码修改后记得更新 @description，于是@description也总是误导读者

文件头注释意在维护代码文件的元信息，以便在分发和部署过程中维护作者版权等信息。 然而在拥有版本控制的代码仓库中，这些信息不再需要手动维护，甚至可以通过git blame查看每一行代码的作者和时间信息。

『建议』：使用版本控制工具，删除文件头注释。版权信息可在构建或分发时生成。

冗余的注释

意图非常清楚的代码原则上不需要注释，多余的注释反而会造成维护性问题。 尤其是非英语母语的作者常常会掉到这个坑里。比如变量和函数的注释：

/*
* 获取用户数目
*/
function getUserCount(){
// 用户的列表
var userList = [];
}

这不是废话么！冗余的注释问题仍然在于维护性，例如调整函数功能、调整参数顺序， 或者更换变量名时我们不得不更新这些注释。否则这些注释就会误导下一个读者。

【建议】：不说废话。

抽取注释到标识符

可能读者也会有这样的经验：当我们写了一大段代码时，往往需要把它们分为几块。 然后在每一块开头添加一段注释。例如：

function calcTotalCharge(movies, user){
// Calculate Movie Charge
var movieCharge = 0;
for(var i=0; i
上述代码中的三段注释确实加速了阅读代码的速度， 但每当代码需要注释才能读懂时就应该警醒：是不是结构设计有问题。 对于上述代码，我们可以通过更加可复用的结构来消除注释：
function calcTotalCharge(movies, user){
return calcMovieCharge(movies) + calcUserCharge(user);
}
function calcMovieCharge(movies){
var total = 0;
for(var i=0; i
代码重构之后原来的注释就变得毫无意义，代码意图都被清晰的表述在标识符的命名中。 通常重构会带来代码量的减小，因为封装了分支、每个单元的逻辑也更加明确。
【建议】：当我们发现不得不进行注释时，需要警醒是否结构设计发生了问题。
有用的注释
至此Harttle已描述了这么多反模式，并非为了说明代码注释不重要。 而是为了说明『代码注释存在的意义在于帮助理解代码本身』。 例如在编写一些Trick，Polyfill，临时代码，以及复杂算法时，注释变得相当重要。 例如：
  • Tricks and Polyfills。有时简单的Trick就可解决多数问题问题， 为没必要编写复杂的普适算法， 例如检测浏览器的DOM API支持，检测AMD/CommonJS环境等等。 这时我们需要清晰地说明这些Trick的意图，甚至可以将这些代码抽离为polyfill模块。
  • 复杂算法。有时我们会编写数学性非常强的算法，一眼望去不知所云。 在开始这些算法前清晰地说明其意图何在，读者也就不必花大功夫读懂这些数学了。
  • 公有接口。模块的对外接口从逻辑上定义了模块类型，公有接口代码也更容易被人读到。 尤其是JavaScript接口：如果不注释options中到底是什么，谁晓得接口如何使用。
感谢你能够认真阅读完这篇文章，希望小编分享的“JavaScript中使用代码注释的注意事项”这篇文章对大家有帮助，同时也希望大家多多支持创新互联，关注创新互联行业资讯频道，更多相关知识等着你来学习!
            
            
                        

            文章名称：JavaScript中使用代码注释的注意事项            

            路径分享：http://cdweb.net/article/ieijop.html

其他资讯