代碼中的Goto真的那么不招人喜歡么？
幾日前在Cafe午餐的時候，大家聊起一些在Windows操作系統源代碼庫中曾經看到過的一些趣聞逸事，比如那個著名的“becauseExchangeisamoron”(正好這天公司的Exchange服務器巨慢，所以大家更是大發一笑)的注釋。這其中有人提到Windows代碼中大量使用goto語句的這個事，這讓我想起這樣一個有趣的問題：
在程序代碼中，我們為什么使用goto，或者，我們為什么不該使用goto呢?
我曾經不止一次地聽某某義正言辭地向我宣傳goto是邪惡的，但如果我追問這么說的理由為何時，通常的答案都是模模糊糊的人云亦云之類的回答。大部分的理由都會指出goto破壞了程序的可讀性和可維護性，如果代碼里到處都是goto來goto去，到***誰都很難搞清程序goto到哪一個地方了。
這看似頗有道理的說辭其實充滿了迂腐的書生氣。稍微有點常識的程序員，難道真會如此到處使用goto么?顯然不會。如果說真的有那么一位程序員是到處在用goto把他的程序邏輯拼接起來的話，那我想他不是天才(匯編寫太多了，到處都要自己跳轉)就是無知(完全無法結構化自己的算法思路)。而軟件開發作為一個工程行業經過這么多年的發展，現實中已經很少會真的有這種濫用goto的現象了。這當然也要感謝于那些關于goto邪惡性的大力宣傳，大家上proceduralprogramming***課開始，就被反復灌輸了“不要用goto，不要用goto”的觀念。
那為什么Windows操作系統代碼中大量使用了goto?是不是微軟總部都雇傭了些爛人，大家都在混飯吃?還是說對于goto的使用是其實很有選擇性的?而從當年goto的大量出現到今天這個關鍵詞在使用C#或Java寫就的程序中幾乎絕跡，這一切，其實都是有其歷史背景和含義的?
要回答這些問題，我們首先討論一下goto在Windows操作系統源碼中的使用。如果仔細觀察一下的話，你會發現goto的使用其實都是在一種很特定的場合，那就是：系統資源的回收和釋放。這里，系統資源可能是一塊字符串內存，可能是某個內核對象(比如event或mutex)的句柄(handle)，也可能是更復雜一些的數據結構。所以，goto出現的代碼段，通常有這樣的結構：
- voidFunc()...{
- ...Magic::Initialize();
- BSTRsomeString=::SysAllocString(L"Somerandomstring");
- hr=CallSomeAPI();
- if(FAILED(hr))
- gotoEXIT;...
- hr=CallSomeOtherAPI();if(FAILED(hr))
- gotoEXIT;
- ...
- EXIT:Magic::Uninitialize();
- ::SysFreeString(someString);
- ...
- }
如此便不難理解為什么goto在這種特定情況下可以簡化代碼編寫的結構，使之更清晰易懂了。試想如果不試用goto，我們的代碼就會變成：
- HRESULTFunc(){
- ...
- Magic::Initialize();
- BSTRsomeString=::SysAllocString(L"Somerandomstring");
- hr=CallSomeAPI();
- if(FAILED(hr))
- {Magic::Uninitialize();
- ::SysFreeString(someString);
- returnhr;
- }
- ...hr=CallSomeOtherAPI();
- if(FAILED(hr))
- {
- Magic::Uninitialize();
- ::SysFreeString(someString);
- returnhr;
- }
- ...returnS_OK;
- }
要做回收處理的資源越多，這樣的寫法就顯得越冗長，因此goto在這里是很自然的一種選擇。
但隨著面向對象的編程模式（Object-OrientedProgrammingParadigm）逐漸地開始取代過程式編程（ProceduralProgramming），程序員開始發現有一種更好的模式（Pattern）可以用來取代goto，那就是RAII（ResourceAcquisitionIsInitialization）模式（“資源分配與初始化同步”）。RAII的主要思想在于兩點：1.對象在且一定在被分配或構造（construct）的時候同時被初始化，這樣就避免了資源在沒有被適當初始化前就被用戶調用。2.對象在被析構（destruct）的時候釋放所占有的資源，這樣就防止了資源泄漏。這個模式最為大家所熟知的應用可能就是C++標準庫或者COM編程中隨處可見的“聰明指針”（smartpointer）了。比如在上面的例子中，我們就可以定義一個MagicPtr的類，然后在類的構造函數里做Initialize，在析構函數里做Uninitialize。而對于BSTR，微軟已經提供了相應的類了，那就是_bstr_t
利用goto來釋放資源在proceduralprogramming的時代是一個自然的選擇，所以在Windows的源代碼中你會看到goto的蹤影，因為Windows在OO思想大行其道之前就已經存在多年了。但隨著OOP的深入人心，遵循RAII來管理資源就成為了最自然的選擇。
另一個重要的原因，就是異常處理（exceptionhandling）概念的興起。goto雖然可以很干凈地解決過程式資源回收的問題，但卻對異常這個東東沒有很好的解決方法。比如上面的程序要是哪里拋出一個異常的話，那goto的部分就根本不會被執行了。而另一方面，RAII卻能很好地解決這個問題，因為在對象離開定義域之前（不管是return了還是exceptionthrown了），析構函數都會被執行的。
其實寫這篇東西的另一個目的也是想說：每一件看似簡單的事情背后，如果你花一些時間去思考和研究，也許就會發現很多更深刻的意義和結果。這并不是要我們變成一個多疑的偏執狂，而是我覺得思索和提問的習慣是有益的。對于一個看似簡單的道理，我們能不能提出讓自己信服的佐證來，我們是否有一種直覺，告訴自己：Iamwonderingifthereismoretoit。事實上，這個世界上的偏執狂是少數，多的，是人云亦云的大眾。
【前幾周熱點周報】
