关于变量的做用域、跨度和存活时间-读《代码大全》

最近在一点一点地读《代码大全（第二版）》，真是一本绝好的书，难怪十几年来会被誉为“程序员的圣经”！虽然曾经不止一次在其余优秀的书籍封底看过出版社对这本书的极力推荐，终于由于期末考的复习太过于枯燥，因而从图书馆找来看看，没想到一看就被前面吸引住了，但直到这个暑假才网购了一本，一点一点的看了起来，颇有味道。

买这本书真的很值，里面好多知识点是课堂上确定不会教的，就连我的在敲代码的过程当中也很难靠本身总结出来的，这也印证了做者在前言中对本书的定位与指望——“但愿缩小本行业中通常商业实践与大师级人物及专家们之间的知识差距”。

进入正题，譬如“变量”这一章，就如文章标题所示，看了“变量”这一章中关于做用域（Score）这一小节才初识了两个名词——变量跨度、变量存活时间。做用域是咱们都熟悉的名词，然后面这两个是我从书上看到的，以为颇有必要记在脑里。下面大概整理出做者对这几个名词的描述：

做用域（score）：能够看做一种衡量变量知名度的方法（做者诙谐的比喻），也称可见性（visibility），指变量在程序内可见和可引用的范围；

跨度（span）：衡量一个变量的不一样引用点的靠近程度，即两个引用点之间相隔的语句数；

存活时间（live time）：指一个变量存在期间（即从变量声明到最后引用该变量的那条语句，跟做用域有点出入）所跨越的语句总数；

***窗口（window of vulnerability）：指介于同一变量多个引用点之间的代码。

 

光是描述不够直观，给出截图：

很明显咱们从三个不一样的图中看到了不一样的描述，即长、短两个修饰词。很明显是第三个图的代码质量是最高的，可能须要说明一下做者区分出这几个名词的意图才能说明状况。

一、从第二个图来看，当变量跨度过大时，***窗口也就越大。此时若是咱们在变量的两个引用点之间的代码进行了某个操做，而这个操做可能会不当心或者不适当地修改了该变量的值，那么在下一个引用点中所用到的变量值将会是错误的。这也就是为何这一范围内的代码被称为***窗口的缘由。

为了减小这一类 bug 的发生，写代码时应该尽可能局部化变量引用，将对某个变量的使用集中在一块儿，以缩小***窗口范围，也就是缩小变量的跨度。此外，在一个相对较集中的代码范围内使用某个变量，使得咱们在阅读、复查代码时所关注的范围更小。任何人（包括写代码时）都不喜欢在读代码时目光不得不跳来跳去的搜索某个变量最近被赋值为何了吧？

二、变量跨度这一律念必定是存在于变量存活时间的范围内的，那么一样的道理，缩短了存活时间也可以减少***窗口带来的威胁。短的变量存活时间除了使代码更具可读性，还可使得咱们在修改代码时的关注范围更小，有利于重构的进行。

譬若有时须要把原来顺序执行的代码改成循环结构时，存活时间短的变量就可使得咱们不容易忽略掉那些离循环结构太远的初始化代码，循环次数控制变量常常出错不少就是源于这一问题。

再如重构，在《重构》中做者说“Moving methods is the bread and butter of refactoring（转移方法是重构的根本）”，而 Move Mothod 这个重构手法又必须创建在 Extract Mothod （提取方法）之上，毕竟当咱们恰当地提取方法以后才可以转移这个方法到合适的地方去。可是若是某个变量的存活时间很长，代码中间隔着使用到了该变量，那咱们还怎么提取方法呢？更谈不上转移方法了。

 

小结：

一、看了《代码大全》，才知道之前本身写代码是多么糟糕；

二、写这篇文章的缘由，是想要记住这几个关于衡量变量使用状况的名词，而想要记住这几个名词的缘由，是想要促使本身之后在写代码时会天然而然地想到这几个名词，接着又会联想到关于变量使用时应该遵照的原则；

三、最后想说的是，这些内容真的是课堂上、其余书都不怎么可以学习到的，即便别人的代码已经遵照了这些原则，我也未必可以很快地注意到原来还有这么一个注意点呢。总之一句话，《代码大全》绝对值得看！O(∩_∩)O