編輯─編譯─執行循環
寫一個 C 程式，不是一次轟轟烈烈的創作；而是你一遍又一遍轉著的一個緊湊小循環。你編輯原始碼、把它編譯成可執行的東西、執行它看看會怎樣，然後——幾乎總是——因為它錯了或還不完整，再回去編輯。一圈又一圈。這個節奏就是編輯─編譯─執行循環，是系統開發每日的心跳。
具體來說，一圈長這樣。編輯：在編輯器裡改你程式的文字。編譯（常叫「建構」）：執行編譯器，像 gcc main.c -o prog，它檢查你的程式碼，若無致命錯誤，就產生一個可執行檔。執行：把它跑起來，像 ./prog，觀察輸出或當機。然後讀懂出了什麼錯——一個指著某行的編譯錯誤、一個錯誤的結果、一個記憶體區段錯誤——再回去編輯把它修好。在 C 裡，編譯這一步自成一道關卡：許多錯誤在那裡就被攔下，程式根本還沒執行——這正是「編譯式語言」為你買到的好處之一。
為何重要：身為系統程式設計師，你大半時間都花在這個循環裡，所以它的速度與清晰度，形塑了你整段體驗。這正是為什麼建構系統、快速的編譯器與良好的錯誤訊息如此重要，也是為什麼人們努力把循環縮短——一次緩慢的編譯或一個含糊的錯誤，會拉長每一圈。理解這個循環，也替你會碰到的兩類截然不同的問題定了框：編譯期錯誤（建構拒絕通過）與執行期錯誤（建好了卻行為失常），這兩者的除錯方式完全不同。
在命令列上典型的一圈：在編輯器裡編輯 hello.c，接著執行 gcc -Wall hello.c -o hello，再執行 ./hello。如果 gcc 印出錯誤，你根本沒機會執行——你修好它指名的那一行，再編譯一次。
編輯、編譯、執行、重複——編譯器就是執行前的那道關卡。
「它編譯過了」不等於「它是對的」。編譯器攔下型別與語法錯誤，但大量錯誤——邏輯錯、未定義行為、當機——只有真正執行時才會現身，有些甚至那時也不現身。通過編譯這道關卡是必要的，而非充分的。