原文：https://jason.pureconcepts.net/2018/09/practices-write-readable-code-less-complex/；
作者：Jason McCreary，軟件工程師，專注於PHP和iOS應用。
譯文：https://mp.weixin.qq.com/s/qcfmgSUidceAUHDxbBehOQ；
譯者：彎月，責編：胡巍巍
這是一篇值得收藏起來，隔三差五就拿來重讀的文章！因為作者向你保證，他“遇到的所有糟糕的代碼，都是因為沒采納這些實踐經驗。而任何一段優秀的代碼，都採納了至少部分實踐經驗。”還等什麼？趕快看看這些經驗就是什麼吧？
我已經寫了20年代碼了，在此期間曾與17個團隊共事過，使用不同的語言做過數百個項目。
這些項目從最簡單的博客網站，到支持每秒3000多次請求的API，還有曾經熱賣過的應用。
根據這些經驗，再結合我讀過的書，我認為編程中最重要的是：可讀性。
1.可讀性
表面上看來，可讀性似乎很主觀。不同語言、代碼、和團隊對於可讀性的定義不盡相同。但如果深入本質的話，就會發現代碼可讀性有一些非常關鍵的因素。
許多程序員太傾向於計算機了，只要程序能運行就一了百了。儘管是老生常談，但這種方式完全斷絕了人參與的可能性。
最近幾個月， 我在努力將這些人為因素提煉成11條寫程序的實踐經驗，專門討論如何增強可讀性並降低複雜度。
我在BaseCode中寫過這些詳細內容，並將其應用到真實世界的代碼片段中。
許多人會認為這些太基礎、無關緊要，可以忽視。但我可以向你保證，我遇到的所有糟糕的代碼都是因為沒采納這些實踐經驗。而任何一段優秀的代碼都採納了至少部分實踐經驗。
2.格式
我們在格式上消耗了太多精力。製表符還是空格，Allman還是K&R。總會有一天，你會意識到格式在編程中並不是最重要的。
選擇一種格式，應用到代碼中，然後將這個過程自動化。然後就可以重新專注於寫代碼本身了。
3.代碼
所有註釋掉的代碼塊、未使用的變量和無法到達的的代碼都是垃圾。他們就像在對讀者說，“我不關心這段代碼”。
於是惡性循環開始了。日復一日，死代碼最終會埋葬你的代碼。這正是經典的破窗效應。
必須要找出並幹掉死代碼。雖然不需要把精力主要放在這裡，但一定要時時留意。更多代碼規範請看這篇文章《優秀 Java 程序員寫代碼的風格》。
4.嵌套代碼
邏輯幾乎是一切代碼的基礎。我們寫代碼是為了做決策、迭代和計算。一般情況下都會導致分支或嵌套，從而造成嵌套得很深的代碼塊。
雖然計算機很容易閱讀這種代碼，但對於人類則是非常大的精神負擔。因此，代碼會變得複雜、難以閱讀。應該通過防禦語句、提前返回或使用函數式編程等方式消滅嵌套代碼。
5.使用對象
儘管現在是面向對象編程的時代，我們依然使用了過多的原始指令。
長長的參數列表，雜亂的數據，自定義的數組或字典結構等。這些都可以重構成對象。
這樣不僅能讓數據結構變得正規，還能容納所有重複的、使用原始數據的重複的邏輯。
6.大型代碼塊
雖然沒有具體的數字，但代碼塊的長度應該是有限制的。如果你認為你的代碼塊過大，就應該對其進行識別、重組並重構。
這個簡單的過程可以讓你確定代碼塊的上下文和抽象級別，以便正確地找出代碼的任務，並將代碼重構到更加易於閱讀、更簡單的代碼塊中。
7.命名規則
當然，好的命名很困難，但只是因為我們人為增加了難度。有個小技巧在編程的許多方面都能用得上，包括命名，那就是——延後。不要糾結某個東西的命名，繼續寫代碼就好。
就算是用一整句話命名一個變量都沒問題，繼續寫代碼就好。我可以保證，當你完成整個功能之後，更好的名字就會浮出水面。
8.刪除註釋
在我看來這一條至關重要，刪了註釋我才能把精力放到可讀性上。不管我如何解釋刪除註釋的必要性，總會有人跟我抬槓，然後舉出一個絕對需要註釋的例子。
當然，如果哈勃望遠鏡要和古老的適配器連接，而後者返回一個意思不明的687，這種情況肯定需要註釋來說明。但大多數其他情況下，你應該儘量重寫代碼使得它不需要註釋也能看懂。
9.合理的返回
我們總是選擇返回最奇怪的值，特別是對於邊界條件的情況。像-1、687或null。然後就得寫很多代碼來處理這些值。實際上，null的創造者稱它為“10億美元的錯誤”。
應該努力返回更有意義的值。理想情況下，最好是即使在反面情況下也能讓調用者繼續執行的值。如果真的是異常情況，那麼最好用其他方式來通信，而不是使用null。
10.三的原則
考慮一下數學上的序列。給出數字2並問你，“下一個數字是什麼？”可能是3可能是4，但也可能是1或2.1。實際上你沒辦法知道。然後我提供了序列中的下一個數字2, 4然後問，“下一個是什麼？”可能是6，8，也可能是16。
同樣，儘管猜對的可能性增加了，但還是不能確定。然後我提供了數列中的第三個數字，2, 4, 16，然後問“下一個是什麼？”有了三個數字之後，程序員的大腦很容易看出這是個平方序列，於是確定下一個數字是256。這就是三的原則。
這個例子雖然跟編程沒關係，但它告訴我們，我們不應該太早做抽象。三的原則能阻止我們過早消除重複的努力，直到有了足夠多的信息後再做出決定。用Sandi Mets的話說，“重複的代價遠遠低於錯誤的抽象。”
11.對稱性
最後一條實踐經驗能給所有代碼的可讀性帶來詩一般的潤色，那就是對稱性。這條來自Kent Beck的《實現模式》一書，書中說到：
代碼中的對稱性是說，同樣的思想在任何地方都使用同樣的實現。
不過說起來容易做起來難。對稱性體現了編程的創造性。它是許多其他實踐的基礎：命名、結構、對象、模式等。不同語言之間、不同代碼之間和不同團隊之間對於對稱性的定義都可能不一樣。
因此，你需要花上許多年去追求對稱性。但是，一旦開始在代碼中使用對稱性，就會迅速呈現純粹的形式，代碼的形狀也會迅速變好。更多代碼規範請看這篇文章《優秀 Java 程序員寫代碼的風格》。
閱讀更多 java面試筆試 的文章
