6個編寫優質幹淨代碼的技巧
【譯者注】作為一名開發者,編寫一手幹淨的代碼很重要,所以在本文中作者先列舉出編寫幹淨代碼的一些好處,再提出6個技巧用於編寫幹淨代碼,供開發者進行參考學習。
以下為譯文:
編寫幹淨的代碼並不是一件容易的事情,這需要嚐試不同的技巧和實踐。問題是,在這個問題上有太多的實踐和技巧,因此開發人員很難進行選擇,所以要把這個問題簡化一下。在本文中,將首先討論編寫幹淨代碼的一些好處,然後將討論6個技巧或者實踐,用於編寫最常用的幹淨代碼。
以下是目錄內容:
引用
編寫幹淨代碼的好處
- 更容易開始和繼續一個項目
- 有利於團隊新員工培訓
- 更容易遵循編碼模式
寫幹淨代碼的技巧
- 編寫可讀的代碼
- 為變量、函數和方法使用有意義的名稱
- 讓每個函數或方法隻執行一個任務
- 使用注釋來解釋代碼
- 保持代碼風格一致性
- 定期檢查你的代碼
關於編寫幹淨代碼的一些想法
寫幹淨代碼的好處
先來了解編寫幹淨代碼的一些好處。其中一個主要好處是,幹淨的代碼可以減少花在閱讀上的時間和理解代碼的時間。淩亂的代碼會減慢任何開發人員的速度,使開發者的工作變得更加困難。代碼越混亂,開發人員就越需要花更多的時間去充分理解它,這樣才能使用這些代碼。而且,如果代碼太亂,開發人員可能會決定停止閱讀這些代碼,並自己從頭開始編寫。
1.更容易開始和繼續一個項目
先用一個簡單的例子來說明這個問題。假設在很長一段時間後我們回到了之前的一個項目,也許在這段時間是一位客戶聯係我們去做了另一項工作。現在,想象一下,那時如果沒有編寫幹淨的代碼,那麼在第一眼看到代碼之後,該是有多糟糕和混亂。而且,也可以知道從當初離開的地方開始編碼有多困難。
因此,現在必須花更多的時間在項目上,因為我們需要理解之前編寫的代碼。這本來是可以避免的,如果從一開始就編寫幹淨的代碼,然而現在必須為此付出代價。而且,舊代碼是如此混亂和糟糕,以至於我們可能決定從頭開始。客戶聽到這些消息後可能不會高興。
另一方麵,幹淨的代碼通常就沒有這個問題。假設前麵的例子是相反的情況,以前的代碼是幹淨和優雅的,那麼理解它需要多長時間?也許隻需要讀幾分鍾的代碼就能理解所有的工作原理,而且我們可能已經開始編寫一段時間了,所以在這種情況下花的精力將明顯小於第一個案例,同時,客戶也不會太在意。
這是編寫幹淨代碼的第一個好處,而且,這不僅適用於自己的項目,也適用於其他開發人員的工作。幹淨的代碼可以更快地啟動工作,任何人都不需要花費數小時來研究代碼,相反,我們可以直接進入工作。
2.有利於團隊新員工培訓
編寫幹淨代碼的另一個好處與第一個好處是密切相關的,那就是可以讓新員工更容易更快地使用代碼。假設我們需要雇傭一個開發人員,那麼她要花多長時間才能理解代碼並學會使用它呢?當然這要視情況而定。如果我們的代碼很亂,寫得很差,她就需要花更多的時間來學習代碼。另一方麵,如果代碼幹淨、易讀、簡單易懂,她將能夠更快地開始她的工作。
有些人可能會說,這不是個問題,因為其他開發人員可以幫助她。當然這是正確的,但是幫助隻應該花很短的時間,是兩三次或者一兩天,而並不應該是兩三個星期。所以,決定雇傭另一個開發人員的目的,是來加速我們的工作,而不是減慢速度,也不是花費更多的時間來幫助她學會使用代碼。
當我們努力寫出幹淨的代碼時,其他人就會向我們學習,也就更容易跟著寫出幹淨的代碼。當然,仍然需要留出一些時間來幫助每個新開發人員了解和理解代碼。當然,我的意思是幾天,而不是幾周。此外,幹淨的代碼將幫助團隊帶來更多的開發人員,並同時幫助他們理解代碼。簡單地說,代碼越簡潔就越容易解釋,誤解也就越少。
3.更容易遵循編碼模式
有一件事需要記住,理解和學習如何使用代碼是一回事。然而,這僅僅是個開始,同時還需要確保開發人員能夠願意遵循我們的編碼模式。當然,使用幹淨的代碼比混亂的代碼更容易實現這個目標。這是很重要的,因為團隊不僅想要編寫幹淨的代碼,而且還一直保持這種模式,這也是需要長期思考的。
另外,如果開發人員不遵循當前的編碼模式該怎麼辦? 這個問題通常可以自行解決。假設有一群人在同一個代碼基礎上工作,其中一個人開始偏離標準樣式。然後,團隊的其他成員將推動這個開發人員遵循標準。她會接受建議,因為她不想離開這個團隊。
還有一種情況,開發人員會說服團隊的其他人采納並遵循自己的編碼模式。如果開發人員提出的編碼模式更幹淨,並且能帶來更好的結果,這當然是件好事。的確,編寫和保持幹淨的代碼並不意味著應該忽略任何改進它的機會,我認為應該始終對目前的做法保持可改進的態度,並努力尋找改進的機會。
因此,如果一個開發人員偏離了當前的模式,同時她的模式也更好,那麼我們做出改變也許會更合適。所以在嚐試其他模式之前,不應該忽視其他人的編碼實踐,同時我們應該繼續尋找改進的餘地。最後,第三種情況。開發人員決定既不采用我們的實踐,也不說服我們采用她的實踐。因為她將決定離開團隊。
寫幹淨代碼的技巧
現在除了討論編寫幹淨代碼的好處,也是時候學習一些技巧來幫助我們實現這個目標了。正如將在以下看到的,幹淨的代碼包含並遵循著一些方法。這些方法使代碼更幹淨、易讀、更易於理解、更簡單。當然沒有必要實施所有的方法,實施並遵循一兩項措施就足以帶來積極的結果。
1.編寫可讀的代碼
的確,所寫的代碼將會機器解釋,然而這並不意味著應該忽視代碼的可讀性和可理解性,因為在將來總會有另一個人會使用我們寫的代碼。即使讓別人無法訪問我們的代碼,但我們自己也可能在將來又重新拾起這些代碼。出於這些原因,讓代碼便於閱讀和理解是符合我們自己的利益的。那麼如何實現呢?
最簡單的方法是使用空格。在發布代碼之前,可以縮減代碼,但是沒有必要讓代碼看起來很小型化。相反,可以使用縮進、換行和空行來使代碼結構更具可讀性。當決定采用這種方式時,代碼的可讀性和可理解性就會顯著提高。然後,看著代碼就可以更容易理解它了。來看兩個簡單的例子。
- // Bad
- const userData=[{userId: 1, userName: 'Anthony Johnson', memberSince: '08-01-2017', fluentIn: [ 'English', 'Greek', 'Russian']},{userId: 2, userName: 'Alice Stevens', memberSince: '02-11-2016', fluentIn: [ 'English', 'French', 'German']},{userId: 3, userName: 'Bradley Stark', memberSince: '29-08-2013', fluentIn: [ 'Czech', 'English', 'Polish']},{userId: 4, userName: 'Hirohiro Matumoto', memberSince: '08-05-2015', fluentIn: [ 'Chinese', 'English', 'German', 'Japanese']}];
- // Better
- const userData = [
- {
- userId: 1,
- userName: 'Anthony Johnson',
- memberSince: '08-01-2017',
- fluentIn: [
- 'English',
- 'Greek',
- 'Russian'
- ]
- }, {
- userId: 2,
- userName: 'Alice Stevens',
- memberSince: '02-11-2016',
- fluentIn: [
- 'English',
- 'French',
- 'German'
- ]
- }, {
- userId: 3,
- userName: 'Bradley Stark',
- memberSince: '29-08-2013',
- fluentIn: [
- 'Czech',
- 'English',
- 'Polish'
- ]
- }, {
- userId: 4,
- userName: 'Hirohiro Matumoto',
- memberSince: '08-05-2015',
- fluentIn: [
- 'Chinese',
- 'English',
- 'German',
- 'Japanese'
- ]
- }
- ];
- // Bad
- class CarouselLeftArrow extends Component{render(){return ( <a href="#" className="carousel__arrow carousel__arrow--left" onClick={this.props.onClick}> <span className="fa fa-2x fa-angle-left"/> </a> );}};
- // Better
- class CarouselLeftArrow extends Component {
- render() {
- return (
- <a
- href="#"
- className="carousel__arrow carousel__arrow--left"
- onClick={this.props.onClick}
- >
- <span className="fa fa-2x fa-angle-left" />
- </a>
- );
- }
- };
2.為變量、函數和方法使用有意義的名稱
來看一看第二個技巧,它將幫助我們編寫可理解和幹淨的代碼。這個技巧是關於變量、函數和方法的有意義的名稱。“有意義的”是什麼意思?有意義的名字是描述性足夠多的名字,而不僅僅是編寫者自己才能夠理解的變量、函數或方法。換句話說,名稱本身應該根據變量、函數或方法的內容和使用方式來定義。
- // Bad
- const fnm = ‘Tom’;
- const lnm = ‘Hanks’
- const x = 31;
- const l = lstnm.length;
- const boo = false;
- const curr = true;
- const sfn = ‘Remember the name’;
- const dbl = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((i) => {
- return i * 2;
- });
- // Better
- const firstName = ‘Tom’;
- const lastName = ‘Hanks’
- const age = 31;
- const lastNameLength = lastName.length;
- const isComplete = false;
- const isCurrentlyActive = true;
- const songFileName = ‘Remember the name’;
- const yearsDoubled = [‘1984’, ‘1987’, ‘1989’, ‘1991’].map((year) => {
- return year * 2;
- });
然而需要注意的是,使用描述性名稱並不意味著可以隨意使用任意多個字符。一個好的經驗則是將名字限製在3或4個單詞。如果需要使用超過4個單詞,說明這個函數或方法需要同時執行很多的任務,所以應該簡化代碼,隻使用必要的字符。
3.讓一個函數或方法隻執行一個任務
當開始編寫代碼時,使用的函數和方法看起來就像一把瑞士軍刀,幾乎可以處理任何事情,但是很難找到一個好的命名。另外,除了編寫者,幾乎沒有人知道函數是用來做什麼的以及該如何使用它。有時我就會遇到這些問題,我在這方麵做的很不好。
然後,有人提出了一個很好的建議:讓每個函數或方法隻執行一個任務。這個簡單的建議改變了一切,幫助我寫出了幹淨的代碼,至少比以前更幹淨了。從那以後,其他人終於能夠理解我的代碼了,或者說,他們不需要像以前一樣花很多時間去讀懂代碼了,功能和方法也變得更好理解。在相同的輸入下,總是能產生相同的輸出,而且,命名也變得容易得多。
如果你很難找到函數和方法的描述性名稱,或者需要編寫冗長的指令以便其他人可以使用,那請考慮這個建議,讓每個函數或方法隻執行一個任務。如果你的功能和方法看起來像瑞士軍刀一樣無所不能,那請你執行這個方法,相信我,這種多才多藝不是一種優勢。這是一個相當不利的情況,可能會產生事與願違的結果。
附注:這種讓每一個函數或方法隻執行一項任務的做法被稱為保持純函數。這種編碼實踐來自於函數式編程的概念。如果你想了解更多,我推薦閱讀《So You Want to be a Functional Programmer series[4]》。
- // Examples of pure functions
- function subtract(x, y) {
- return x - y;
- }
- function multiply(x, y) {
- return x * y;
- }
- // Double numbers in an array
- function doubleArray(array) {
- return array.map(number => number * 2)
- }
4.更容易遵循編碼模式
不管多麼努力地為變量、函數和方法想出有意義的名字,代碼仍然不可能完全清晰易懂,還有一些思路需要進行解釋。問題可能不是代碼很難理解或使用,相反,其他人可能不理解為什麼要實現這個函數或方法,或者為什麼要以特定的方式創建它。意思是,創建函數或方法的意圖還不清楚。
有時可能不得不采用非傳統的方法來解決問題,因為沒有足夠的時間來想出更好的解決方案,這也很難用代碼來解釋。所以,通過代碼注釋可以幫助解決這個問題,也可以幫助我們向其他人解釋為什麼寫了這個方法,為什麼要用這種特定的方式來寫,那麼其他人就不必猜測這些方法或函數的用途了。
更重要的是,當我們使用注來解釋代碼後,其他人可能會找到一個更好的方法來解決這個問題並改進代碼。這是有可能的,因為他們知道問題是什麼,以及期望的結果是什麼。如果不知道這些信息,其他人就很難創建更好的解決方案,或者他們可能不會去嚐試,因為他們認為沒有必要去修改創建者自己的想法。
因此,每當自己決定使用一些快速修複或非傳統的方法時,要用注釋來解釋為什麼這麼做。最好是用一兩行注釋來解釋,而不用別人來猜測。
也就是說,我們應該隻在必要的時候使用注釋,而不是解釋糟糕的代碼。編寫無窮無盡的注釋將無助於將糟糕的代碼轉換成幹淨的代碼。如果代碼不好,應該通過改進代碼來解決這個問題,而不是添加一些如何使用它的說明。編寫幹淨的代碼更重要。
5.保持代碼風格一致性
當我們有自己喜歡的特定編碼方式或風格時,就會在任何地方一直使用它。但在不同的項目中使用不同的編碼風格不是一個好主意,而且也不可能很自然地回到以前的代碼,所以仍然需要一些時間來理解在項目中使用的編碼風格。
最好的方法是選擇一套編碼方式,然後在所有的項目中堅持使用。這樣的話,回到之前的舊代碼會變得更容易。當然,嚐試新的編碼方式是一件好事,它可以幫助我們找到更好的方法來開展工作。但是最好是在不同的實驗項目或練習上嚐試不同的編碼風格,而不是在主要項目上進行。
另外,當我們決定做一些試驗的時候,就應該嚐試多次練習,應該花時間徹底地做好。隻有真正確信喜歡這種做法,並且對它感到滿意時,才應該去實施它。而且決定這樣做的時候,最好應用在所有的項目中。是的,這需要時間,這也會促使我們正確地思考。
6.檢查你的代碼
這是最後一個技巧。不僅僅是編寫幹淨的代碼,還要完成最後的工作,那就是需要維護幹淨代碼。我們應該定期檢查代碼,並試著改進它。否則,如果不審查和更新我們的舊代碼,它很快就會過時,就像我們的設備一樣。如果想讓代碼保持最佳狀態,就需要定期更新它們。
對於每天使用的代碼,情況也是如此。代碼會變得更加複雜和混亂,所有應該避免這種情況發生,並保持代碼幹淨。實現這一點的唯一方法是定期檢查我們的代碼。換句話說,我們需要保持它。對於那些未來不再關心的項目來說,這可能是不必要的,但對其他的來說,維護代碼是工作的一部分。
關於編寫幹淨代碼的一些想法
今天討論的這六種做法,可能不是影響最大的,也可能不是最重要的,但這些是經驗豐富的開發人員最常提到的,這也就是我選擇它們的原因。我希望這些實踐或技巧能夠幫助你開始編寫幹淨的代碼。現在,就像所有的事情一樣,最重要的是開始。所以,至少選一個技巧,然後試一試。
本文作者:Teixeira10譯
來源:51CTO
最後更新:2017-11-02 15:05:28