關於變量的做用域、跨度和存活時間-讀《代碼大全》

最近在一點一點地讀《代碼大全（第二版）》，真是一本絕好的書，難怪十幾年來會被譽爲「程序員的聖經」！雖然曾經不止一次在其餘優秀的書籍封底看過出版社對這本書的極力推薦，終於由於期末考的複習太過於枯燥，因而從圖書館找來看看，沒想到一看就被前面吸引住了，但直到這個暑假才網購了一本，一點一點的看了起來，頗有味道。

買這本書真的很值，裏面好多知識點是課堂上確定不會教的，就連我的在敲代碼的過程當中也很難靠本身總結出來的，這也印證了做者在前言中對本書的定位與指望——「但願縮小本行業中通常商業實踐與大師級人物及專家們之間的知識差距」。

進入正題，譬如「變量」這一章，就如文章標題所示，看了「變量」這一章中關於做用域（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