30多年的軟件經(jīng)驗,總結(jié)出10個編寫出更好代碼的技巧
30 多年的軟件經(jīng)驗,總結(jié) 10 個***妙招。
那么,何以敲出一手好代碼?
好代碼可以定義為易讀、易懂、易調(diào)試、易改,最重要的還要少缺陷。顯然,要想敲出一手好代碼,是要花不少時間,但這在長久來看是有意義的,因為你可以花更少時間及精力去維護和復(fù)用你的代碼。
事實上,我們可以將好代碼等同于可復(fù)用的代碼,這也是下面提到的重要原則之一。代碼可能只是完成了編程工作中短期目標的特定功能,但如果沒人(包括你自己)愿意復(fù)用你的代碼,這代碼在某種程度上可以說是不足且有缺陷的。要么太復(fù)雜、要么太具體、要么在不同情況下極有可能崩掉,或者其他程序員可能不相信你的代碼。
下面無論你的經(jīng)驗水平如何,如果你始終如一地將下面的妙招應(yīng)用到你的代碼中(包括你的實驗或者原型),那么一手好代碼隨手可得。
1、遵循單一責(zé)任原則
函數(shù)在程序員的庫中是單一最重要的抽象形式??梢员粡?fù)用的機會越多,你要寫的代碼就越少,這些代碼就越可靠。遵循 單一責(zé)任原則 的小小函數(shù)更有可能被重新使用。
2、最小化共享狀態(tài)
應(yīng)該將函數(shù)之間的隱式共享狀態(tài)最小化,無論它是文件作用域變量還是對象的成員字段,這有利于顯式地將所需的值作為參數(shù)。當明確函數(shù)實現(xiàn)所需結(jié)果時,代碼變得容易理解和重用。
對此可以得出一個結(jié)論,你應(yīng)該優(yōu)先選擇靜態(tài)無狀態(tài)變量而不是對象的成員變量。
3、本地化副作用
理想的副作用(例如打印到控制臺、記錄、改變?nèi)譅顟B(tài)、文件系統(tǒng)操作等)應(yīng)該放置在單獨的模塊中,而不是分散在整個代碼中。功能上的副作用往往違反了單一的責(zé)任原則。
4、優(yōu)先選擇不可變的對象
如果一個對象的狀態(tài)在其構(gòu)造函數(shù)中設(shè)置一次,并且不再次更改,則調(diào)試變得容易得多,因為一旦構(gòu)造正確就保持有效。這是降低軟件項目復(fù)雜性的最簡單方法之一。
5、多用接口少用類
接受接口的函數(shù)(或C++中的模板參數(shù)或概念)比在類上操作的函數(shù)可重用性更強。
6、對模塊應(yīng)用良好的原則
將軟件項目分解成更小的模塊(例如庫和應(yīng)用程序),以實現(xiàn)模塊化重用。模塊的一些關(guān)鍵原則是:
- 最小化依賴關(guān)系
- 每個項目都應(yīng)該有一個單一明確的功能
- 不要重復(fù)
你應(yīng)該努力讓你的項目保持小巧和明確。
7.避免繼承
在面向?qū)ο缶幊讨?,繼承,特別是虛擬函數(shù)在可重用性方面往往是一個死穴。我很少能成功地使用能覆蓋類的庫。
8.同設(shè)計和開發(fā)一樣進行測試
我并不是測試驅(qū)動開發(fā)的鐵桿擁護者,但在你開始編寫測試代碼時,編寫測試自然遵循了許多指導(dǎo)方針。它也有助于早點將錯誤暴露出來。避免編寫無用的測試,良好的編碼意味著更高級的測試(例如,單元測試中的集成測試或功能測試)在顯示缺陷方面更有效。
9.優(yōu)先選擇而不是手寫標準庫
我無法告訴你需要多久才能看到一個 std :: vector 或 std :: string 更好的版本,但它幾乎總是浪費時間和精力。除了一個顯而易見的事實,那就是你正在把 bug 引入一個新的地方。(見技巧10)其他程序員不太可能重用您的代碼,而不是那些被廣泛理解、支持和測試的代碼。
10.避免寫新代碼
最重要的一點是,每位程序員應(yīng)遵循:“ The best code is the code that isn’t written ”(***的代碼是不用被復(fù)寫的代碼)。你的代碼越多,缺陷就越多,找到并修復(fù) bug 就越困難。
在編寫一行代碼之前先問問自己,有沒有一個工具,函數(shù)或庫已經(jīng)做了你所需要的功能?你真的需要自己去實現(xiàn)這個功能,而不是調(diào)用另一個已經(jīng)存在的功能嗎?
總結(jié) 編程就好比是一種藝術(shù)形式或者一項運動,你只有通過不斷地練習(xí),不斷地向他人學(xué)習(xí),才能不斷地提高代碼的質(zhì)量,這些都將有利于你成為更加高效的程序員。