程式設計習慣No. 1：使用goto

關於禁止使用goto可以追溯到許多結構化程式設計工具還未面世的時代。如果程式設計師想要建立一個迴圈或跳到另一段程式中，那麼他們需要輸入goto後再跟一個行號。過了幾年之後，編譯器團隊讓程式設計師使用字串標籤取代行號。這在當時被認為是一個熱門的新功能。

有的人認為這會導致“義大利麵條式程式碼”。程式碼會變得不可讀，並且很難理解程式碼的執行路徑。執行緒混亂，纏纏綿綿到天涯。Edsger Dijkstra就三令五申地表示應該禁止這個命令，他有一份詼諧的手稿，題目為《Goto語句害人不淺》。

但絕對的分支是沒有問題的。這就讓人糾結了。通常，巧妙的 break 語句和return 語句可提供一個非常乾淨的關於程式碼在那個時候執行什麼的宣告。有時候，新增 goto 到case語句會比更恰當的多級巢狀的if-then-else語句塊更易於理解。

也有反例。在蘋果的SSL堆疊中的“goto fail”安全漏洞就是最好的例子之一。但是，如果我們能夠仔細避免case語句和迴圈的一些尷尬問題，那麼我們就可以嵌入良好的絕對轉移，使閱讀程式碼的人更容易明白這是怎麼回事。我們可以插入break和return 語句，讓每一個人感覺更清潔和更愉快——可能得除了goto的敵視者。

程式設計習慣No. 2：成功避開文件

我的一個朋友有一個非常精明的老闆，這位老闆雖然從來沒有寫過任何程式碼，但卻秉持著每一個功能都必須包含在文件中的理念。哪個程式設計師不提供註釋，那麼他就會受到懲罰。所以，我的朋友在他的編輯器中聯入了一個有點像人工智慧的玩意兒，於是乎，他的每一個功能就都有幾行“文件”了。因為這位精明的老闆還不夠聰明到能理解這些註釋其實啥意思也沒有，所以我的朋友逃過一劫。他的程式碼常常被作為正式文件。我想，他應該快要升職了！

許多函式方法，甚至一些類或多或少都能自文件化。冠以insertReservation或cancelReservation或 deleteAll 等名稱的函式並不需要多此一舉來解釋它們的作用。為函式取一個正確的名字往往就足夠了。事實上，這比寫一段長長的註釋要好，因為函式名可以出現在程式碼中的其他地方。而文件只能默默地呆在某個角落。自文件化的函式名可以改進它們出現的每個檔案。

在有些情況下，寫文件甚至會導致情況變糟。例如，當代碼瞬息萬變，團隊像瘋了似的重構的時候，文件會產生分歧。程式碼是這樣寫的，但文件解釋的還是四五個版本以前的情況。這類“過時”的文件通常位於程式碼頂部，有的人會在這裡對程式碼應該發生什麼作一個美好總結。因此，儘管重構團隊已經仔細修改了相關的註釋，但還是會遺漏檔案頂部的這段“美好總結”。

當代碼和文字出現分歧的時候，註釋就變得毫無價值，甚至會產生誤導。在這樣的情況下，良好的自文件化的程式碼顯然勝出了。

程式設計習慣No. 3：一行寫太多程式碼

老闆突然發神經地給團隊發了一封討厭的郵件：為了執行非常嚴格的風格規定，我們大家都必須重寫我們的程式碼。最神奇的要求是：每個行為或步驟或子句必須各自成行。你不能使用點語法連續呼叫函式。在一個分支語句中，你不能有兩個及以上返回布林值的子句。如果要定義變數，那麼另起一行。如果你正在做一個複雜的計算，那麼不要使用括號。每個片段也自成一行。

他認為他的這個法令將能使除錯變得更加容易。就像你單步除錯程式碼一樣，偵錯程式會一個動作一個動作地前進。這樣就不會卡在某一行。而且更容易執行。

但是這樣一來，鍵盤上的回車鍵煩不勝煩，因為我需要不斷地插入行。而且我敢肯定，老闆因此還可以到處吹噓他的團隊能寫多少行程式碼。

唉，有時在同一行中宣告一堆變數反而更容易；有時把所有的布林子句放在一起反而更簡單——一切都能變得更加緊湊。那也意味著，我們可以在螢幕上看到更多的邏輯而無需滾動滑鼠。更易於閱讀就意味著理解起來更快。這才是簡單的精粹。

程式設計習慣No. 4：不宣告型別

那些熱愛型別化語言的人認為，如果為每個變數新增明確的資料型別宣告，就可以寫出更好的、沒有錯誤的程式碼。花一點時間來拼寫型別，能幫助編譯器在程式碼開始執行之前標誌愚蠢的錯誤。可能會讓人覺得痛苦，但很有幫助。這是程式設計中停止bug的一種有備無患的方法。

但是時代變了。許多較新的編譯器完全可以智慧地通過檢視程式碼來推斷型別。它們會向後和向前瀏覽程式碼，直到可以肯定這個變數是string 還是int，抑或其他。如果這些被檢視的型別不成佇列，那麼錯誤標誌就會點亮。因此再也不需要我們輸入變數的型別了。

這意味著我們現在可以在程式碼中省略掉一些最簡單的宣告。程式碼更清潔，而且閱讀程式碼的人也猜得出for迴圈中命名為 i 的變量表示一個整數型。

程式設計習慣No. 5：搖擺不定的程式碼

有的程式設計師在程式碼上特別優柔寡斷，猶豫不決。先是一開始將值儲存為字串，然後又解析成整數。接著又轉換回字串。這是非常低效的，你甚至可以感覺到CPU在咆哮這種浪費負載的行為。聰明的程式設計師之所以能快速地編碼，是因為他們事先會設計架構，以儘量減少轉換。他們的程式碼能更快地執行是因為他們有一個良好的規劃。

但是，不管你信不信，這種搖擺不定的程式碼有時候也是有意義的。比如說，你有一個非常棒的庫，在它專有的黑盒子裡能做無數智慧的事情。如果庫需要字串的資料，那麼你就給它字串，即使你剛將這個資料轉換成為整數型。

當然，你可以重寫所有的程式碼，以儘量減少轉換，但是這需要時間。而且，有時候讓程式碼稍微多花點額外時間來執行也未嘗不可，因為重寫程式碼需要耗費我們更多的時間。有時，揹負這樣的技術債務比一開始就正確構建的成本要更低。

有的時候，庫不是專有的程式碼，但那些你以前全部自己寫的程式碼是你獨有的。有的時候，再次轉換資料比重寫庫中的所有程式碼要快得多。所以，就讓它這樣吧，就讓程式碼搖擺吧。

程式設計習慣No. 6：編寫你自己的資料結構

有一個標準規則是，程式設計師在完成資料結構課程的第二年，不應該寫用於儲存資料的程式碼。基本上我們需要的所有的資料結構，已經有人寫好了，而且其程式碼已歷經多年的測試和再測試。它和語言捆綁在一起，而且常常是免費的。你的程式碼只能造就bug。

但有時你會發現資料結構庫有點慢。有時它們會迫使我們使用標準的，但於我們的程式碼卻是錯誤的結構。有時庫會把我們推向在使用結構之前重新配置資料的地步。有時庫會包含一些所謂有備無患的保護功能，如執行緒鎖，但其實我們的程式碼並不需要。

如果遇到這種情況，那麼就應該著手寫我們自己的資料結構。這或許能讓你做得更快，做得更多。而且程式碼會變得更清潔，因為我們不會包括那些多餘的用於格式化資料來完成一些功能的程式碼。

程式設計習慣No. 7：在中間打破迴圈

有一個規則制定小組宣稱，每個迴圈都應該有一個“常量”，也就是說當這個邏輯語句為true的時候，迴圈一直執行。當常量一定不會是true的時候，迴圈才會結束。這是考慮複雜迴圈的好方法，但它會導致愚蠢的禁令——例如禁止我們在迴圈中間使用return 和break 語句。這一條也包含在禁止goto語句的規則中。

這個理論是好的，但它通常會導致更復雜的程式碼。請看下面這個簡單的案例，遍歷陣列，將找到的元素傳遞給test函式，並將該元素返回：

while(i<a.length){
...
if(test(a[i])thenreturna[i];
...
}

“迴圈常量”愛好者會要求我們增加一個布林變數，命名為notFound，然後這樣使用：

while((notFound)&&(i<a.length){
...
if(test(a[i]))thennotFound=false;
...
}

如果這個布林值能夠合理地命名，那麼這就是一段很棒的自文件化的程式碼，更易於大家理解。但這也增加了複雜性。這意味著你需要分配另一個區域性變數，並堵塞暫存器，因為編譯器也許還不能足夠智慧到解決這個問題。

有時候，一個goto 語句或一個跳轉會更乾淨利索。

程式設計習慣No. 8：使用短變數名（i和x和and也是有意義的）

Edgar Allan Poe這位詩人和小說家曾經說過，在一個故事中的每一個詞都應該是有內涵的。編碼規則也強調如此。變數名應該說明這個變數的所作所為。那些使用駝峰式大小寫的方法來寫變數名，以表達關於變數細節的Java程式設計師深以為然，於是一個又一個瘋狂長度的變數名出爐了。有些程式設計師寫的變數名，會組合五六個甚至更多的詞語。

但有的時候，使用單個字母作為變數名反而會更方便。有時在迴圈迭代中只使用i或j會更簡單。有時使用字母a代表array ，l代表list會更便捷，即使是字母l和數字1看上去很難辨別。

正如這篇文章前面鼓勵的是自文件化的程式碼，而非長長的註釋。在上述情況下，單個字母的變數名也是自文件化的。字母 i 是通用的迭代器。只要是程式設計師立刻就會懂。

程式設計習慣No. 9：重新定義運算子和函式

一些最有趣的程式語言允許你去做一些特別詭異的事情，例如重新定義元素的值，就如同常量一般。例如Python，你可以輸入TRUE=FALSE（在Version2.7及之前的版本）。這並不會產生某種邏輯崩潰，或導致宇宙終結——僅僅只是互換了TRUE和FALSE的含義。你也可以在C前處理器和一些其他語言中玩玩類似於這樣的危險遊戲。還有一些語言允許你重新定義運算子，如加號。

當然這是延伸了，不過有一個觀點是，在一個大的程式碼塊內，當重新定義一個或多個所謂的常量時，速度會更快。有時老闆會要求程式碼做一些截然不同的事情。當然，你可以修改程式碼的每個事件，或者，你可以重新定義。這讓你看上去像一個天才。不必重寫一個龐大的庫，只需翻轉一下，就可以做相反的事情了。