程序猿应该避免写凝视

“程序猿工作效率有多高。取决于他大脑中对当前项目的熟悉程度,即变量名称、数据结构、编程接口以及工具类甚至是文件夹等。这些细节记住的越多,效率也越高。”

凝视不是用来翻译程序代码的。用代码能说清楚的东西。就不要再用自然语言费脑子去写了。集中精力写出最优雅、质量高的代码才是首要的。

这并非说能够全然不写凝视,而是说不要为了加入不必要的凝视而打乱你的思路。我非常赞成这两篇文章的观点《世上最糟糕的两个变量名》以及陆其明老师翻译的《避免在代码里写凝视》,有一个好的变量名、方法名事实上就是一段非常好的凝视了,并且还会“自己主动更新”,你不用在未来优化这段代码的时候同步更新凝视。

我们写凝视的目的不是说这段代码怎样运行。而是想解释为什么要这么运行,这也正是与其研究代码、研究凝视,不如研究写下这些代码的人。借用一下阿特伍德的博客原文中的样例:

r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );

这段代码没有凝视就全然看不懂了,假设加上一点凝视说明一下则效果要好得多:

// 用“牛顿-拉夫逊”近似法求解n的平方根
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
System.out.println( "r = " + r );

这么一来凝视的作用就完毕体现出来了,可是假设不用凝视呢?像这样:

private double SquareRootApproximation(n) {
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
return r;
}
System.out.println( "r = " + SquareRootApproximation(r) );
“我一行凝视也没有加,但这段神奇的代码如今已经非常easy理解了。”

我们每一个人在项目中应该都有遇到过这种事情。与其让他写下一堆凝视,不如告诉他命名的重要性,能全然、准确地描写叙述所代表的事物。这无疑能提高整个项目的可读性。

在命名方面也有一些陷阱,假设一个命名不能做到准确的命名,这就和一段错误的凝视描写叙述正确的行为一样让人更加费解,并且假设你在命名一个类时没有考虑太多,在后期发觉不好,要更换名称的时候会非常麻烦,你可能要改头文件的名称、实现文件的名称。各种调用以及导入的地方,甚至是创建文件时自己主动生成的一点凝视,就这要求我们在创建一个类和方法时。头脑中至少要对将要做的事情“优化”好几遍。能准确无误的表达自己想表达的东西。对一些人来说。这个过程会非常累,但确实是有必要。

对命名使用准确的对仗词,有助于保持代码一致性,终于提高可读性。针对变量使用的对仗词:

  • begin/end
  • first/last
  • locked/unlocked
  • min/max
  • next/previous
  • old/new
  • opened/closed
  • visible/invisible
  • source/target
  • source/destination
  • up/down
针对方法名使用的对仗词:
  • add/remove
  • increment/decrement
  • open/close
  • begin/end
  • insert/delete
  • show/hide
  • create/destroy
  • lock/unlock
  • source/target
  • first/last
  • min/max
  • start/stop
  • get/put
  • next/previous
  • up/down
  • get/set
  • old/new
对于子程序(方法实现)过长的情况,要检查子程序的设计以及实现是否合理。必要的时候把子程序拆分为多个子程序,保持每一个子程序的高内聚性(仅仅做好一件事)总是有优点的。

千万不要把 bool 当成函数參数》这篇文章提出的问题非常有意思,对于布尔变量,能够给布尔变量赋予隐含“真假”含义的名字。

最后。对你自己写下的代码。不要心存畏惧,不要把它尘封在那里,保持它的活跃度。在适当的时间对它进行重构。假设要问重构到什么地步,那就是:到你没时间重构为止



posted @ 2016-01-31 21:52  phlsheji  阅读(269)  评论(0编辑  收藏  举报