這裡將彙整目前已發表文章的目錄，歡迎訂閱以接收文章更新資訊。 A 核心觀念篇 核心觀念介紹。建立觀念基礎，閱讀時背景知識、程式撰寫經驗需求低。 日期 文章 2022-10-10 A0004 程式設計是有趣的堆積木遊戲

程式設計很有樂趣 「程式設計很有樂趣」，這句話恐怕相當多人不認同。大多數人寫程式通常關心著撰寫功能、擔心著易讀與否、經歷著無盡的 Debug；這樣的經驗是辛苦的、沉重的、痛苦的，自然與樂趣是沾不上邊。那為什麼又說有樂趣呢？千萬別誤會了，這裡所說的樂趣不是指以虐待自己為樂、吃苦當吃補的那種，而是像打球、看劇、玩遊戲等等所能獲得的樂趣，是真正能享受在其中的體驗。 之所以會覺得程式設計沒樂趣，關鍵是沒接觸到有趣的觀念；如果能把這些觀念帶到程式設計的過程中，相信看待程式設計的方式一定會有所改變。 程式設計是堆積木遊戲 要解釋為什麼有樂趣之前，我們需要新的比喻來看待程式設計。這裡不再老梗地說寫文章、種田、蓋房子等比喻，畢竟印象中作家、農夫、建築師通常都是辛苦的，用於解釋樂趣稍嫌不夠準確。這個新的比喻，就是堆積木遊戲。 玩遊戲應該沒有人覺得沒樂趣吧？那為什麼是堆積木而不是其他遊戲呢？

精簡與準確 「精準」 是另一個讓程式碼易讀的重要特性。要注意的是，這裡說的精準，指的是精簡與準確。必須兩個概念都要具備，才算得上是符合這個特性。 精簡 精簡一個容易想像的概念。假設有兩段程式碼可以完成同一件事情，其中一個用了2000行，另一個用了20行，請問哪一個比較易讀呢？在大多數的情況下，精簡的20行會比繁複的2000行來得更容易掌握、更容易理解。所以說，很多時候使用較少的程式碼可以達成易讀。這真是多麼簡單的概念！ 準確 不過，只抓住精簡的原則是不夠的。當我們只考慮要用較少程式碼完成目標的時候，可能會省略了關鍵程式碼。怎麼說呢？觀察[[B0001 易讀程式碼的特性：白話]]與[[B0002 易讀程式碼的特性：直觀]]提到的例子，不難發現那些完全不白話、完全不直觀的寫法，所需要的程式碼都是比較少的，但他們都是易讀的反指標。所以不能一味地追求精簡，而是在精簡程式碼的過程中，守住一個底線，一個至少能清楚明白表達行為的底線，稱作準確。 這裡雖然用白話與直觀作為舉例，但準確並不是白話與直觀的綜合體。仔細分辨的話，白話與直觀屬於語意上的易讀特性，而準確則是邏輯行為上的易讀特性。有時候程式碼已經白話且直觀了，卻可能邏輯行為讓人難以掌握，變得很失焦，也就是不準確。

程式碼是寫給誰看的？ 「程式碼是是寫給人看的」 這件事情，在程式設計領域已經是老生常談了；正因為要給人看，所以如何讓程式碼好閱讀，就是很重要的課題。這就是所謂的易讀性（或許有些人稱作是可讀性，指的是同一件事情）。許多文獻都強調了這件事情， 這裡僅舉例列出2則經典書籍的名言供參考。 「任何傻子都能寫出電腦能懂的程式碼，而好的程式設計人員才能寫出人類能懂的程式碼」[^1] -- Martin Fowler et. al., Refactoring: Improving the Design of Existing Code, 1999. [^1]: "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." Martin Fowler et. al., Refactoring: Improving the Design of Existing Code, 1999. 「寫程式要優先給人看，然後才是電腦」[^2]

講白話吧！ 一般而言，程式碼是否易讀沒有客觀標準定義，好比人們在判斷一篇文章是平易近人還是艱澀難懂，也沒有統一的客觀方式去決定。即使如此，我們還是可以依據是否滿足某些特性來大致判斷程式碼是否相對易讀。這些特性中，「白話」 是一個很重要的指標。 下面例子可以說明白話的程式碼是什麼概念。 極度難以理解的程式碼 請先嘗試閱讀並理解下面這段程式碼。 int getLight_1() { static int a = 0;

別讓程式碼加密了 回顧B0001 易讀程式碼的特性：白話，我們提到了易讀程式碼的特性：白話；藉由簡單的例子來比較白話與不白話的差異，也將不白話的程式碼比喻是需要翻譯機做對應才能理解。 在這裡我們進一步比喻，這些需要翻譯機的程式碼，就像是很怕人（也包括作者自己）一眼就看懂的樣子，於是把文字給加密了。如果不想讓自己的程式碼需要翻譯機，就要學習怎麼別將文字加密。說來有趣，人們寫程式竟然直覺是寫出加密的程式碼，反倒是要學習技巧來讓程式碼不要加密。 下面提供一些參考方法，以避免寫出加密的程式碼。 方法1：避免魔術數字 魔術數字（Magic Number），是指程式碼中難以辨識其物理意義的數字。我們用B0001 易讀程式碼的特性：白話出現過的例子說明魔術數字的概念。

直接，不要省略 關於程式碼是否易讀，除了白話之外，「直觀」 也是很重要的特性。所謂的直觀，就是程式碼的字面邏輯要符合直覺，想做的事情都直接表達，不要省略。 忍不住要問為什麼 請嘗試閱讀以下敘述，感受一下文字表達是否足夠直觀。 敘述組1： 方向盤向右轉讓汽車向左轉。 按2次向上音量鍵，才讓音量增加。

寫程式如禪學 「見山是山，見山不是山，見山只是山」^1，這是禪學領域知名的人生哲理，描述著人生會經歷的三個階段。其意思是，在人生年輕歷練尚淺時，看到山就是山，不會有太多的想法；當進入中年，有一定人生歷練的時候，看到山總是會有些不一樣的體悟出來，或許覺得壯闊、或許覺得莊嚴、或許覺得寧靜，端看山所帶給自己的感覺，而不是山本身；最後到了經歷更多的老年，在看透了許多事情後，看到山反而沒有之前的包袱，認為山就是山，沒有必要過度解讀。 這樣的人生三境界，在寫程式的領域也是如此。 境界一：見山是山 初次接觸寫程式的時候，通常都是從語法開始學起，所以看到語法就是語法，也就是見山是山。比方說，當學到了 if、for、class、function 等等的語法，心中所想的是，需要判斷式就加入 if、需要批次處理就加入 for、需要將資料包起來就加入 class、需要打包一段程式碼就加入 function。見山是山，語法就是語法，任何語法使用起來都是直觀的。 境界二：見山不是山 隨著寫程式的時間越來越長，不論是自己經驗的心得、還是前人提供的指導、或者書本撰寫的知識，對於語法的使用概念會越來越不單純。可能會有以下情境：

程式問題很多的原因 為什麼會遇到程式問題很多呢？主因是過度關注應用，導致忽略程式設計本身的學問。 程式設計的目的終究是要提供應用，人們透過程式設計讓計算機幫忙完成特定任務，像是導航程式用於規劃路線、遊戲程式用於休閒娛樂、通訊程式用於遠距溝通…等等；反過來說，不能提供應用的程式，就不是一個有效的實作。然而，當程式設計人員過度在乎應用，忽略了程式設計本身，往往會產出 Bug 很多、效率很差的不堪用程式。舉例來說，一個導航程式如果規劃出很糟的路線、規劃路線要等很久、找不到目的地、導航中途閃退、語音不符導航內容…等等，使用者應該很難接受吧？這些問題，肯定不是在寫程式的時候，就想把問題呈現給使用者，讓使用者接觸這些不堪用的功能；真實情況應該是對程式設計本身的掌握度太低，難以做出功能精準、沒有問題的程式。要探討這個現象，可以從當代程式設計過度依賴高階語言與教育與訓練不足來討論。 當代程式設計過度依賴高階語言 隨時時代的演進，程式語言的發展越來越高階，使得現任何想法的實現通常不需要寫太多的程式碼就能辦到；因此，同樣應用的實現，高階語言寫起來通常比低階語言來的簡潔，可以更專注於應用的開發。比方說字串的串接，高階語言通常只要將兩個字串加起來就可以了，但低階語言就需要在意字串串接後的記憶體空間夠不夠，需要先處理好記憶體，才能真的做串接。由於方便性，漸漸地程式設計人員只關心把應用做出來，至於如何寫出好的程式碼就變得不是那麼重要了。這樣的陳述，並不是要貶低高階語言，畢竟高階語言的出現，本來就是為了讓程式設計可以專注在功能的開發、應用的實現，而不用對枝微末節的項目費神。 要深究「為什麼方便性會讓人忽略寫好程式碼的重要性」，可以從程式的本質談起。所謂程式的本質，就是在處理邏輯。一個邏輯，就是根據一個條件去做某一件事情；然後將許許多多的邏輯堆疊起來，就是一個程式了。以這個定義來看，只要會下 if-else 條件式，應該沒有寫不出來的程式；加上高階語言通常又提供了很多方便的語法與套件，要具體做什麼或許都一兩行就能辦到，堆疊起來簡單方便。長期如此下來，自然自信心膨脹，認為什麼程式都能寫得出來。