歡迎光臨
每天分享高質量文章

優秀程式員寫程式碼一定會用的 11 條經驗

  • 可讀性
  • 格式
  • 死程式碼
  • 巢狀程式碼
  • 使用物件
  • 大型程式碼塊
  • 命名規則
  • 刪除註釋#
  • 合理的傳回
  • 三的原則
  • 對稱性

這是一篇值得收藏起來,隔三差五就拿來重讀的文章!因為作者向你保證,他“遇到的所有糟糕的程式碼,都是因為沒採納這些實踐經驗。而任何一段優秀的程式碼,都採納了至少部分實踐經驗。”

還等什麼?趕快看看這些經驗就是什麼吧?

img

我已經寫了20年程式碼了,在此期間曾與17個團隊共事過,使用不同的語言做過數百個專案。

這些專案從最簡單的部落格網站,到支援每秒3000多次請求的API,還有曾經熱賣過的應用。

根據這些經驗,再結合我讀過的書,我認為程式設計中最重要的是:# 可讀性。#

可讀性

錶面上看來,可讀性似乎很主觀。不同語言、程式碼、和團隊對於可讀性的定義不盡相同。但如果深入本質的話,就會發現程式碼可讀性有一些非常關鍵的因素。

許多程式員太傾向於計算機了,只要程式能執行就一了百了。儘管是老生常談,但這種方式完全斷絕了人參與的可能性。

最近幾個月, 我在努力將這些人為因素提煉成11條寫程式的實踐經驗,專門討論如何增強可讀性並降低複雜度。

我在BaseCode中寫過這些詳細內容,並將其應用到真實世界的程式碼片段中。

許多人會認為這些太基礎、無關緊要,可以忽視。但我可以向你保證,我遇到的所有糟糕的程式碼都是因為沒採納這些實踐經驗。而任何一段優秀的程式碼都採納了至少部分實踐經驗。

格式

我們在格式上消耗了太多精力。製表符還是空格,Allman還是K&R;。總會有一天,你會意識到格式在程式設計中並不是最重要的。

選擇一種格式,應用到程式碼中,然後將這個過程自動化。然後就可以重新專註於寫程式碼本身了。

死程式碼

所有註釋掉的程式碼塊、未使用的變數和無法到達的的程式碼都是垃圾。他們就像在對讀者說,“我不關心這段程式碼”。

於是惡性迴圈開始了。日復一日,死程式碼最終會埋葬你的程式碼。這正是經典的破窗效應。

必須要找出並幹掉死程式碼。雖然不需要把精力主要放在這裡,但一定要時時留意。

巢狀程式碼

邏輯幾乎是一切程式碼的基礎。我們寫程式碼是為了做決策、迭代和計算。一般情況下都會導致分支或巢狀,從而造成巢狀得很深的程式碼塊。

雖然計算機很容易閱讀這種程式碼,但對於人類則是非常大的精神負擔。因此,程式碼會變得複雜、難以閱讀。應該透過防禦陳述句、提前傳回或使用函式式程式設計等方式消滅巢狀程式碼。

使用物件

儘管現在是面向物件程式設計的時代,我們依然使用了過多的原始指令。

長長的引數串列,雜亂的資料,自定義的陣列或字典結構等。這些都可以重構成物件。

這樣不僅能讓資料結構變得正規,還能容納所有重覆的、使用原始資料的重覆的邏輯。

大型程式碼塊

雖然沒有具體的數字,但程式碼塊的長度應該是有限制的。如果你認為你的程式碼塊過大,就應該對其進行識別、重組並重構。

這個簡單的過程可以讓你確定程式碼塊的背景關係和抽象級別,以便正確地找出程式碼的任務,並將程式碼重構到更加易於閱讀、更簡單的程式碼塊中。

命名規則

當然,好的命名很困難,但只是因為我們人為增加了難度。有個小技巧在程式設計的許多方面都能用得上,包括命名,那就是——延後。不要糾結某個東西的命名,繼續寫程式碼就好。

就算是用一整句話命名一個變數都沒問題,繼續寫程式碼就好。我可以保證,當你完成整個功能之後,更好的名字就會浮出水面。

刪除註釋

在我看來這一條至關重要,刪了註釋我才能把精力放到可讀性上。不管我如何解釋刪除註釋的必要性,總會有人跟我抬槓,然後舉出一個絕對需要註釋的例子。

當然,如果哈勃望遠鏡要和古老的配接器連線,而後者傳回一個意思不明的687,這種情況肯定需要註釋來說明。但大多數其他情況下,你應該儘量重寫程式碼使得它不需要註釋也能看懂。

合理的傳回

我們總是選擇傳回最奇怪的值,特別是對於邊界條件的情況。像-1、687或null。然後就得寫很多程式碼來處理這些值。實際上,null的創造者稱它為“10億美元的錯誤”。

應該努力傳回更有意義的值。理想情況下,最好是即使在反面情況下也能讓呼叫者繼續執行的值。如果真的是異常情況,那麼最好用其他方式來通訊,而不是使用null。

三的原則

考慮一下數學上的序列。給出數字2並問你,“下一個數字是什麼?”可能是3可能是4,但也可能是1或2.1。實際上你沒辦法知道。然後我提供了序列中的下一個數字2, 4然後問,“下一個是什麼?”可能是6,8,也可能是16。

同樣,儘管猜對的可能性增加了,但還是不能確定。然後我提供了數列中的第三個數字,2, 4, 16,然後問“下一個是什麼?”有了三個數字之後,程式員的大腦很容易看出這是個平方序列,於是確定下一個數字是256。這就是三的原則。

這個例子雖然跟程式設計沒關係,但它告訴我們,我們不應該太早做抽象。三的原則能阻止我們過早消除重覆的努力,直到有了足夠多的資訊後再做出決定。用Sandi Mets的話說,“重覆的代價遠遠低於錯誤的抽象。”

對稱性

最後一條實踐經驗能給所有程式碼的可讀性帶來詩一般的潤色,那就是對稱性。這條來自Kent Beck的《實現樣式》一書,書中說到:

程式碼中的對稱性是說,同樣的思想在任何地方都使用同樣的實現。

不過說起來容易做起來難。對稱性體現了程式設計的創造性。它是許多其他實踐的基礎:命名、結構、物件、樣式等。不同語言之間、不同程式碼之間和不同團隊之間對於對稱性的定義都可能不一樣。

因此,你需要花上許多年去追求對稱性。但是,一旦開始在程式碼中使用對稱性,就會迅速呈現純粹的形式,程式碼的形狀也會迅速變好。

贊(0)

分享創造快樂