編寫可讀代碼的藝術

《編寫可讀代碼的藝術》，這本書有一些有趣的地方，可以觀摩觀摩。

把信息塞進名字中

避免空泛的名字，像tmp和retval，除非使用它們有特殊的理由。

使用具體的名字來更細緻地描述事物——ServerCanStart()這個名字就比CanListenOnPort更不清楚。

給變數名帶上重要的細節——例如，在值為毫秒的變數後面加上_ms。

為作用域大的名字採用更長的名字——不要用讓人費解的一個或兩個字母的名字來命名在幾屏之間都可見的變數。對於只存在於幾行之間的變數用短一點的名字更好。

有目的的使用大小寫、下劃線等——例如，你可以在類成員和局部變數後面加上「_」來區分它們。

不會誤解的名字是最好的名字

當要定義一個值的上限或下限時，max_和min_是很好的前綴。對於包含的範圍，first和last是最好的選擇。對於包含/排除範圍，begin和end是最好的選擇，因為它們最常用。

當為布爾值命名時，使用is和has這樣的詞來明確表示它是個布爾值，避免使用反義的詞(例如disable_ssl)。

要小心用戶對特定詞的期望。例如，用戶會期望get()或者size()是輕量的方法。

大家都願意讀有美感的代碼

如果多個代碼塊做相似的事情，嘗試讓它們有共用的模塊。

把代碼按「列」對齊可以讓代碼更容易瀏覽。

如果在一段代碼中提到A、B和C，那麼不要在另一段中說B、C和A。選擇一個有意義的順序並始終用這樣的順序。

用空行來把大塊代碼分成邏輯上的「段落」。

什麼地方不需要注釋

能從代碼本身中迅速地推斷的事實。

用來粉飾爛代碼（例如蹩腳的函數名）的「拐杖式注釋」——應該把代碼改好。

你應該記錄下來的想法

對於為什麼代碼寫成這樣而不是那樣的內在理由（「指導性批註」）。

代碼中的缺陷，使用像TODO：或者XXX：這樣的標記。

常量背後的故事，為什麼是這個值。

站在讀者的立場上思考

預料到代碼中哪些部分會讓讀者說：「啊？」，給它們加上注釋。

為普通讀者意料之外的行為加上注釋。

在文件/類的級別上使用「全局觀」注釋來解釋所有的部分是如何一起工作的。

用注釋來總結代碼塊，使讀者不致迷失在細節中。

把更多的信息裝入更小的空間里

當像「it」和「this」這樣的代詞可能指代多個事物時，避免使用它們。

盡量精確的描述函數的行為。

在注釋中用精心挑選的輸入/輸出例子進行說明。

聲明代碼的高層次意圖，而非明顯的細節。

用嵌入的注釋（如Function(/*arg =*/…)）來解釋難以理解的函數參數。

用含義豐富的詞來使注釋簡潔。

讓代碼的控制流更易讀

在寫一個比較時，把改變的值寫在左邊，並且把更穩定的值寫在右邊更好一些。

你也可以重新排列if/else語句中的語句塊。通常來講，先處理正確的/簡單的/有趣的情況。有時這些準則會衝突，但是當不衝突時，這是要遵循的經驗法則。

三目運算符必須在結構非常簡單的情況下使用。

嵌套的代碼塊需要更加集中精力去理解。應該把它們改寫成更加「線性」的代碼來避免深嵌套。

通常來講提早返回可以減少嵌套並讓代碼整潔。「保護語句」（在函數頂部處理簡單的情況時）尤其有用。

減少變數的數量和讓它們盡量「輕量級」來讓代碼更有可讀性

減少變數，即那些妨礙的變數。

減小每個變數的作用域，越小越好。

只寫一次的變數更好。那些只設置一次值的變數（或者const、final、常量）使得代碼更容易理解。

本文轉載自【編程牛人】

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！