# A0003 程式碼是寫給人看的。易讀很重要
## 程式碼是寫給誰看的？
**「程式碼是是寫給人看的」** 這件事情，在程式設計領域已經是老生常談了；正因為要給人看，所以如何讓程式碼好閱讀，就是很重要的課題。這就是所謂的**易讀性**（或許有些人稱作是**可讀性**，指的是同一件事情）。許多文獻都強調了這件事情，
這裡僅舉例列出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]
> -- Steve McConnell, _Code Complete: A Practical Handbook of Software Construction, Second Edition_, 2004

[^2]: "Write programs for people first, computers second." Steve McConnell, _Code Complete: A Practical Handbook of Software Construction, Second Edition_, 2004

## 易讀性的重要
即使知道文獻都這樣說、大師們、前輩們都認為易讀性很重要，但為什麼大多數程式碼還是寫得晦澀難懂呢？或許是沒有認真思考過「為什麼易讀性很重要」吧！要知道，人們通常是透過思考並理解原因後，才能將知識與觀念內化，然後才是實踐。換句話說，如果沒有打從心底覺得易讀性很重要，自然是不會在寫程式的時候把它放在心上。

下面就來探討易讀的重要性、與不願意寫易讀程式碼的原因吧。

### 程式碼是需要維護與複用的
對於程式碼要寫得易讀，常見的解釋一般都圍繞在程式碼是需要**維護**與**複用**做討論，比方說會有下面這些考量：
* 很多時候程式碼可能不只有自己要用，當別人要使用的時候，我們會希望易讀才容易複用。
* 雖然有的時候程式碼只有自己要用，但人是健忘的，幾個月後如果還需要使用或調整，不易讀的程式碼會很難召回記憶，要維護或複用都很困難。
* 即使撰寫中的程式碼只是一次性測試或實驗用的，也很可能在未來重新挖出來使用。如果不易讀，挖出來使用就會很痛苦。

總結來說，寫一個不易讀的程式碼，就可能在未來害人害己。如果想趨吉避凶，最好還是讓程式碼易讀。

### 懶惰是人類的天性
既然考量都是很好的、都是很實際會遇到的情況，為什麼還不足以說服大家身體力行去提升易讀性呢？根本原因就在於 **「惰性」**！

人總是會想要偷懶的。對於未來的事情，會有不想處理的惰性。試想，這些維護與複用的考量，倘若未來不發生，為什麼要現在處理呢？別人要使用是未來式、忘記怎麼處理自己寫過的程式碼是未來式、重複使用一次性的程式碼也是未來式。只要是未來式就不一定會發生；只要僥倖不發生的話，這樣不處理就能獲得一種**賺到了的體驗**。即使未來發生了，等發生的時候再煩惱吧，甚至煩惱的可能也不是自己呀，何必當下操這個心呢？**反正程式碼能完成當前的目的就好，易讀性再說**。

### 讓程式行為正確其實更重要
「反正程式碼能完成當前的目的就好」、「以後的事情以後再說」等想法是不容易反駁的，畢竟我們本來就不可能、也不應該做太久遠以後的考量，才不至於讓整個程式藍圖過於龐大，導致無法完成。無怪乎人們總是不願意多付出心力在易讀性上面了。

然而，把**未來不一定會有用處**作為偷懶的藉口是陷入一個**盲點**。程式碼易讀的重要性其實在**當下**就非常重要了！這是一個想偷懶也躲不掉的理由：**讓程式行為正確**。怎麼說呢？首先，我們應該重新檢視一下**程式碼**到底是做什麼用的。

所謂程式碼，就是程式設計人員撰寫出來的文字描述，去告訴電腦要做到什麼事情；也就是說，電腦要做什麼事情，依照的是該程式碼所代表的**行為集合**。電腦不可能直接知道程式設計人員想要做什麼事情，一切都要透過程式碼才能辦到。所以要思考的是**要如何確保撰寫出來的程式碼，等價於自己想讓電腦執行的行為集合**。這個等價性，是不是就應該**讓程式碼易讀，然後透過閱讀理解，直觀去確認是否跟自己心中所想的相符**呢？一份不易讀的程式碼，想要精準理解該程式碼所代表的行為集合，是非常困難的。

graph TD;
PROGRAMMER["程式設計人員"] --> CODE["程式碼"] ;
CODE --> CPU["電腦（運算平台）"];

當程式碼難以理解，就很難確保電腦進行我們所預期行為；而電腦產生不預期行為，就是所謂的 Bug，是程式設計人員不樂見的。減少 Bug、讓**程式行為正確**不是未來的問題，是真真切切當下就要處理的事情，實在不應該有任何偷懶的理由！

### 慢慢來比較快
除了沒想清楚易讀性是當下的課題外，另一個常見的偷懶理由是**想更快完成程式碼**。因為要讓程式碼易讀，可能需要用字白話、邏輯直觀、概念精準，即使不花額外敲程式碼的時間，也需要花思考的時間來做規劃。

不管易讀性，程式碼寫起來真的會比較快嗎？在這樣認知前，請先釐清一個事實：**一個程式的完成，不是程式碼敲完就好了，是必須行為正確**。經驗上，要保證程式行為正確，敲完程式碼後通常要經歷 Debug 階段才算達成。所以可以這麼說，一個完整的程式撰寫流程，應該包括敲程式碼與 Debug。

撰寫一個不易讀的程式碼，可能花費 20% 的時間在完成程式碼，然後因為程式碼不易讀，就會花費 80% 時間進行 Debug 與修正程式碼；相反地，撰寫一個易讀的程式碼，撰寫當下不容易出錯，因此時間佔比往往會反過來：花費 80% 的時間在完成程式碼，而只要 20% 的時間 Debug 即可。時間佔比相反的原因，主要在於撰寫易讀程式碼通常 Debug 的情況會很好掌握，而偷懶隨意寫程式碼的 Debug 的情況會很難掌握，不小心就會弄成解不掉的 Bug，甚至需要重寫程式碼才有機會解決問題！所以**要覺得撰寫易讀程式碼的過程看起來很慢，但其實最後是比較快完成程式的**。

### 愉快地寫程式吧
再退一步講好了。假設不管有沒有寫易讀程式碼，最後完成程式所花的總時間相同，那應該要選擇什麼方式進行比較好呢？一般而言，單純寫程式碼是愉悅的，但 Debug 是痛苦的；如果是看著難懂的程式碼，肯定會更加痛苦。請試著思考下面的例子，哪一個是比較愉悅的體驗：
* 花費4小時建構一個易讀的程式碼，加上1小時的 Debug
* 花費1小時建構一個難讀的程式碼，加上4小時的 Debug

答案應該是顯而易見的。撰寫易讀程式碼吧！人生已經很苦了，就不要再讓完成程式的過程也是痛苦的了。

## 易讀程式碼好處多，不寫嗎？
總結來說，不要再為了莫名的理由而偷懶寫逃避易讀性了。確保易讀性，不但容易保證程式碼行為，還能更快完成程式，而且體驗愉悅。易讀程式碼好處多多，不寫嗎？**程式碼是寫給人看的**，這個經典文獻的金玉良言，相信只要人類還需要寫程式碼的一天，就不會有過時的時候吧！

---

## 延伸閱讀
[B0001 易讀程式碼的特性：白話](/bdQxzTadSP-HIfXlQZHxLg)
[B0002 易讀程式碼的特性：直觀](/dlMMeRFHTbODazo1B5DgCw)
[B0003 易讀程式碼的特性：精準](/v3PlMq0cQkO25DqTpRhXYg)