Heading for the future

代码精进之路读后感(六-结束篇)

继续拜读范老师的代码精进之路,这一篇说的使我们最常用的注释

注释就是对代码的解释。注释不需要运行,它是用来提高代码的可读性和可维护性的。但是不好的注释会使代码变得更糟糕,使人更抓狂

首先我们一定要明白一个事情:源代码不一定要添加注释

在理想状态下,代码不需要注释,理想的代码,命名恰当,结构清晰逻辑顺畅,含义显而易见。但是正如一个作者无法预料他的作者能否读懂他的意思一样,一个程序员也没办法保证他的作者能否理解他的意思,所以我们就需要来使用注释进一步提高可读性。

使用注释该注意什么:

1.不能过度的依赖注释,我们首先要保证准确的命名,清晰的结构,而不是因为使用注释就不注意命名规范

  例如

var name1; // first name
var name2; // last name

  虽然有注释但是读起来很费劲,那我们就不如改用以下方式

var firstName;
var lastName;

2.不可以滥用注释

  由于注释部分不被执⾏,那么就可以被⽤来注释掉⼀些不需要的东⻄。⽐如,在正式的产品代码中,注释掉调试信息、代码块、俏皮话等等。

  ⽐如说,看到下面的注释,你是不是立即就转移注意⼒了? 我理解这个注释的初衷是幽默⼀下,但是众⼝难调,这样的注释有些人感觉到的不是幽默,而是散漫和业余。

// 哈哈,有没有⼈姓好,叫“好名字”?
var firstName;
var lastName;

 

总结⼀下,注释是代码的⼀部分,是需要阅读的内容,⽬的是让其他⼈能更好地理解我们的代码,写注释需要我们有“⽤户思维”。虽然也有过度依赖注释的情况,但是,对于⼤部分程序员来说,问题还是注释太少,⽽不是太多。

 

常见的注释类型

  1.是记录源代码版权和授权的

    ⼀般放在每⼀个源文件的开头,说明源代码的版权所有者,以及授权使用的许可方式,或者其他的公共信息

  2.是用来生成用户文档的

    ⽐如Java Doc。 这部分的作⽤,是⽤来⽣成独⽴的、不包含源代码的⽂档。 这些⽂档帮助使⽤者了解软件的功能和细节,主要⾯向的是该软件的使⽤者,⽽不是该软件的开发者。 ⽐如Java的API规范的⽂档。

  3.是用来解释源代码的

    就是帮助代码的阅读者理解代码。这是⼤家默认的注释类型,

 

注释的三项原则

  1. 准确,错误的注释⽐没有注释更糟糕。
  2. 必要,多余的注释浪费阅读者的时间。
  3. 清晰,混乱的注释会把代码搞得更乱。

 

合理的运用好注释必然会让我们代码的可读性更上一层楼,就不会出现怼着一个函数看半天还不知道这个函数是在做什么的情况了,加上注释吧骚年,幸福你我他

到此关于代码精进之路的阅读就结束了,虽然后续还有很多篇,例如内存规范之类的,前端基本上是涉及不到的,所以我也就不在将后续的发表读后感了,通过读了读范老师的几篇文章感触颇多,意犹未尽的同学可以直接去看范老师的文章

posted @ 2019-05-03 17:08  一只菜鸟攻城狮啊  阅读(589)  评论(0编辑  收藏  举报