《The Art of Readable Code》学习笔记(一)

放寒假回家有些颓废,就是不想看书。但是已经大三了,春节过后就要找实习了。哎,快乐的大学生活终于要过去了。

先从简单的书看起吧!在图书馆借了本《The Art of Readable Code》,就是教你咋写好优雅的代码的,感觉还不错。整理一下学习心得。

书中总共分了四大部分,总共15个章节。我也打算边看边记下笔记,用四篇文章来记录一下学习心得。
如下:

  • 第一部分:初级的一些优化
  • 第二部分:简化循环和逻辑
  • 第三部分:重新组织你的代码
  • 第四部分:一些选定的主题

前戏

看原版书而不是翻译版的有个好处就是,英文的表达很精确。

整本书始终就围绕了一个主题来写的

Code Should Be Easy to Understand

什么样的代码才算好呢?
有一个判断的标准:缩短别人能看明白你代码的时间。这时候估计又有同学会问了,我写的就是给自己看的,或者团队里就我一个人,设计到实现到测试全是我一个人,要写给别人明白干什么?好吧,老实说,我之前也是这样想的。“别人”不一定是其他人,也可能是三个月后的你自己。

代码越短越好吗?
代码当然应该清晰易懂,这谁都知道,但是往往大牛们都不这么想。一些大牛认为代码越短越好,在leetcode上经常可以看见这样的话:Python One line Solution Beats 100% .确实只用了一行,但是往往读懂它却要用半天:(
还有三元运算符? :到底该不该用,简单的情况下是可以使用的,比如return max == -1 ? 0 : max可以不必用if else来代替了,但是有些情况下,如果为了把代码写到一行中而在三元运算符中添加复杂的逻辑,以至于别人为了看懂你这行代码,要去查一查其中运算符的优先级,那就不是好代码了。

第一部分 : 初级的一些优化

比如,取个好点的名字,写上必要的注释,格式化代码等等,它们影响了代码库中的每一行代码,虽然这些改变不破坏整体的逻辑,但是却能使代码更容易读懂。

A. 在名字中包含信息

Man-Eater plant(食人花)这个名字让人一看就懂。

  1. 使用特定的单词。比如def GetPage(url){...}这个就不够具体,get本身有很多种意思,你到底是要干啥?替换成具体的单词,FetchPage() DownLoadPage()都是可以的,让人一看就明白了。
  2. 避免使用通用的名字。像tmp,retval,我以前就喜欢这样写,为什么?还不是嫌取个名字太麻烦了,自己英文水平又不行,用拼音吧,也太low了。这种变量名字不能传达任何信息,尽量不要用。除非在某些情况下,比如,交换两个变量的值,这时候需要一个中间变量tmp,这个没问题,大家都也都能看明白。多重循环的时候,也避免使用i,j,k这样没有任何信息的变量名,可以使用club_i, members_i, users_i这样的,或者缩写ci,mi,ui防止搞混淆。
  3. 使用更详细的名字。尽量详细的将信息表达在名字中,ServerCanStart()相对于CanListenOnPort来说就很含糊。
  4. 添加额外的关键信息。比如时间单位,开始和结束时间,start_ms end_ms后面就可以加上单位,来防止在接下来遇到其他不同单位时间的变量中出错。
  5. 为大范围的变量起个长名字,小范围的变量可以取个短一点的名字。如果变量只存在于一个很小的范围中,比如只有几行,那么map<String, int> m这样就没毛病。但如果map存在一个很大的范围里面,m就不便于阅读了。
  6. 使用大写,下划线等去表达特定的信息。比如在C++中,类中的变量名以下划线结尾,比如offset_,这就说明它是一个类的成员变量,而不是局部变量。

B. 名字不能模棱两可

英语中有很多模棱两可的单词,比如filter,results = Database.all_objects.filter("years <= 2011")。那问题来了,results中到底是包含的<= 2012的还是not <= 2012
表达范围:如果要表示高低的范围,那么加上max_min_是很好的选择;如果要表示两个边界都包含在内,那么应该用firstlast;如果要左闭右开,那么应该选择beginend
命名一个布尔型变量的时候,要多使用ishas等使它表达的意思更明确。尽量不要使用负面的词汇,比如,不应该用boolean disable_ssl = false而是用boolean use_ssl = true
还有命名的时候要注意大家默认的习惯,比如会认为带有get的方法是一个代价很小的轻量级的方法,但你却用getMean()这个方法去计算了一个时间复杂度为O(n*n)的平均值,这时候就应该写成computeMean而不是getMean。

C.在代码中审美

这让我想起了云栖社区之前搞的一个活动"第83行代码",就是大家秀一秀自己写的代码。反正,我看一些大牛的代码,就感觉:哇塞!大牛就是大牛,写代码都感觉像是在创作,虽然看不懂写的啥吧,但是单单从审美上就让你震撼了。那么如何使自己代码看起来更优雅呢?

  • 如果有很多个代码块做的事相似,那么也给它们相同的风格,包括注释上下对齐,保持注释结构一致,保持代码的对齐等等。
  • 给多个变量赋值,选择有意义的排列顺序,并且始终保持这种排序。
  • 将许多个声明语句分成块,在相应的块上注释好大概的功能。
  • 给代码分段,每段前写上注释,段与段之间一个空格隔开。
  • 还有就是大括弧的问题
class Logger{
...
}
or
class Logger
{
...
}

这两种写法都没问题,但要选择一种,并且始终保持风格一致,不能混用。

D.学会去写注释

什么是好的注释?有一个判断标准:让读代码的人尽可能多地知道和写代码的人一样的信息。

  • 当然,注释不是什么都要地方都需要写的。一些能直接从变量名读出来的信息,那就不要画蛇添足了。
  • 也不要为了注释而注释。可能会觉得不写注释不妥,那就干脆写一个注释吧!但是注释中其实没有包含什么有用信息。
  • 也不要为了修正代码中糟糕的变量名来写注释,这时候应该直接去修改代码,而不是在注释中写明。
  • 注释也斜体文本可能就是直接的记录了你当时写代码的想法,这也ok。写出来或许对读代码的人有帮助。
  • 为代码中的一些缺点注释:比如
标记 意思
TODO: 我还没抽空去解决的事
FIXME: 这里的代码有点问题
HACK: 对于这个问题的解决方案有待改善
XXX: 危险!重灾区。。
  • 给自己定义的常量注释
  • 给代码的关键部分,主要功能写注释。
  • 写总结性的注释,让读者不要纠结于一些小细节之中。可以宏观的角度看这些代码,而不是去计较每一行。

写注释反正对于我是蛮难的,一方面写的代码不多,感觉自己注释可能会很幼稚,一方面也觉得写好一个注释要花时间。看了这一章,以后写项目代码的时候,无论如何,也要适当的把注释加上。

E.使自己的注释精确、紧凑

感觉这个没什么好说的,谁都不喜欢听别人唠叨:)那就从我们写注释开始吧!

  • 避免使用它,这个,那个这样的代词,防止产生歧义
  • 润色一些那些“唠叨的话
  • 阐释你的方法的输入、输出时,用一些例子
  • 陈述你代码中和宏观的意图,而不是纠结于细节之中。
  • 用一些能表达更多信息的词,可能一个词就能说明你原来用一句话想说明的意思。

ok!刚看完了这本书的第一部分,万事开头难。寒假生活开始喽!
剩下的我会陆续更新哒~
希望对你有所帮助( ̄︶ ̄)↗ 

上一篇:想在数据泄露事件中幸存?你需要了解这些


下一篇:如何使用LDAP用户单点登录到Horizon桌面和应用