關於goto語句有兩篇著名的文章，Dijkstra的go to statement considered harmful，和Knuth的structured programming with goto statement。Dijkstra主張完全摒棄goto語句的使用，Knuth則主張disciplined use of goto statement。從他們的文章看，不管是Dijkstra還是Knuth都同意：程式碼是靜態的文字，計算是動態的過程；靜態的程式碼作為描述動態的計算的媒介，要讓程式設計師能夠清楚地reason about computation，不然就容易引入bug。

結構化程式設計的順序、分支、迴圈三種控制結構提供了簡單的控制流（control flow）。如果畫成流程圖，形狀都簡單。順序結構自不必說，每一條語句都是一個盒子，只有一個入口一個出口。同時，可以把順序結構的連續若干條語句整體視作一個盒子，只有一個入口一個出口。而分支結構、迴圈結構在必要的時候也可以視作一個盒子，只有一個入口一個出口。這兩種結構的內部流程，一方面可以區域性地（locally）看，另一方面可以把內部的巢狀結構視作盒子。那麼在不使用goto語句，而只使用三種控制結構的情況下，任何一個C函式的流程圖，透過把適當的連續的語句視作一個盒子，都可以是三種控制結構之一的最簡單形態。而這種粗粒度的流程圖的每一個盒子，又可以區域性地看。這就使得“關注點分離”（separation of concerns）成為可能。於是程式設計師可以相對較容易地推斷程式在某一時刻是否滿足期望的狀態和不變性（invariant）。（對於non-trivial演算法，要證明演算法滿足某一性質，仍然是non-trivial。）

Goto語句的問題在於，沒有原則的goto語句的使用（undisciplined use of goto statements）容易使程式控制流變亂，使得上述由粗粒度到細粒度的閱讀變得困難，背離了關注點分離原則，嚴重影響程式設計師reason about computation。Goto語句甚至可以使得流程圖不是一個平面圖（planar graph）。

Knuth贊成節制地使用goto語句。如果有什麼原則要遵循的話，我想應該是讓程式設計師能夠容易地reason about computation。Knuth在他的偉大作品TeX裡多處使用了goto語句，但是程式碼仍然很清晰。有興趣的讀者可以參閱《TeX: the program》。C++ STL的設計者Alexander Stepanov也是Knuth關於goto語句看法的追隨者。他在給A9員工的課程（Youtube上有影片）中提到，在程式邏輯可以建模成有限狀態機（finite state automata）的時候，就可以使用goto語句。

C語言是面向過程的語言，在程式設計的時候，一般會遵從結構化程式設計的要求。結構化程式設計要求模組單入口，單出口，而goto語句則容易破壞這種結構，所以不建議使用。但這並不是強制的，只是一種建議，有時goto可以大幅度簡化程式碼量，在保證程式碼足夠清晰明確下，偶爾使用也是可以的。

簡單案例：

跳轉到標籤AA，實現迴圈。

#include

注意，標籤不要寫在定義變數的地方。