程式設計師如何寫出優質乾淨的程式碼，這6個技巧你不能錯過！
編寫乾淨的程式碼並不是一件容易的事情，這需要嘗試不同的技巧和實踐。
作為一名開發者，編寫一手乾淨的程式碼很重要.
先列舉出編寫乾淨程式碼的一些好處，再提出6個技巧用於編寫乾淨程式碼，供開發者進行參考學習。
開頭
寫乾淨程式碼的好處
先來了解編寫乾淨程式碼的一些好處。其中一個主要好處是，乾淨的程式碼可以減少花在閱讀上的時間和理解程式碼的時間。凌亂的程式碼會減慢任何開發人員的速度，使開發者的工作變得更加困難。程式碼越混亂，開發人員就越需要花更多的時間去充分理解它，這樣才能使用這些程式碼。而且，如果程式碼太亂，開發人員可能會決定停止閱讀這些程式碼，並自己從頭開始編寫。
1.更容易開始和繼續一個專案
先用一個簡單的例子來說明這個問題。假設在很長一段時間後我們回到了之前的一個專案，也許在這段時間是一位客戶聯絡我們去做了另一項工作。現在，想象一下，那時如果沒有編寫乾淨的程式碼，那麼在第一眼看到程式碼之後，該是有多糟糕和混亂。而且，也可以知道從當初離開的地方開始編碼有多困難。
因此，現在必須花更多的時間在專案上，因為我們需要理解之前編寫的程式碼。這本來是可以避免的，如果從一開始就編寫乾淨的程式碼，然而現在必須為此付出代價。而且，舊程式碼是如此混亂和糟糕，以至於我們可能決定從頭開始。客戶聽到這些訊息後可能不會高興。
另一方面，乾淨的程式碼通常就沒有這個問題。假設前面的例子是相反的情況，以前的程式碼是乾淨和優雅的，那麼理解它需要多長時間?也許只需要讀幾分鐘的程式碼就能理解所有的工作原理，而且我們可能已經開始編寫一段時間了，所以在這種情況下花的精力將明顯小於第一個案例，同時，客戶也不會太在意。
這是編寫乾淨程式碼的第一個好處，而且，這不僅適用於自己的專案，也適用於其他開發人員的工作。乾淨的程式碼可以更快地啟動工作，任何人都不需要花費數小時來研究程式碼，相反，我們可以直接進入工作。
2.有利於團隊新員工培訓
編寫乾淨程式碼的另一個好處與第一個好處是密切相關的，那就是可以讓新員工更容易更快地使用程式碼。假設我們需要僱傭一個開發人員，那麼她要花多長時間才能理解程式碼並學會使用它呢？當然這要視情況而定。如果我們的程式碼很亂，寫得很差，她就需要花更多的時間來學習程式碼。另一方面，如果程式碼乾淨、易讀、簡單易懂，她將能夠更快地開始她的工作。
有些人可能會說，這不是個問題，因為其他開發人員可以幫助她。當然這是正確的，但是幫助只應該花很短的時間，是兩三次或者一兩天，而並不應該是兩三個星期。所以，決定僱傭另一個開發人員的目的，是來加速我們的工作，而不是減慢速度，也不是花費更多的時間來幫助她學會使用程式碼。
當我們努力寫出乾淨的程式碼時，其他人就會向我們學習，也就更容易跟著寫出乾淨的程式碼。當然，仍然需要留出一些時間來幫助每個新開發人員瞭解和理解程式碼。當然，我的意思是幾天，而不是幾周。此外，乾淨的程式碼將幫助團隊帶來更多的開發人員，並同時幫助他們理解程式碼。簡單地說，程式碼越簡潔就越容易解釋，誤解也就越少。
3．更容易遵循編碼模式
有一件事需要記住，理解和學習如何使用程式碼是一回事。然而，這僅僅是個開始，同時還需要確保開發人員能夠願意遵循我們的編碼模式。當然，使用乾淨的程式碼比混亂的程式碼更容易實現這個目標。這是很重要的，因為團隊不僅想要編寫乾淨的程式碼，而且還一直保持這種模式，這也是需要長期思考的。
另外，如果開發人員不遵循當前的編碼模式該怎麼辦? 這個問題通常可以自行解決。假設有一群人在同一個程式碼基礎上工作，其中一個人開始偏離標準樣式。然後，團隊的其他成員將推動這個開發人員遵循標準。她會接受建議，因為她不想離開這個團隊。
還有一種情況，開發人員會說服團隊的其他人採納並遵循自己的編碼模式。如果開發人員提出的編碼模式更乾淨，並且能帶來更好的結果，這當然是件好事。的確，編寫和保持乾淨的程式碼並不意味著應該忽略任何改進它的機會，我認為應該始終對目前的做法保持可改進的態度，並努力尋找改進的機會。
因此，如果一個開發人員偏離了當前的模式，同時她的模式也更好，那麼我們做出改變也許會更合適。所以在嘗試其他模式之前，不應該忽視其他人的編碼實踐，同時我們應該繼續尋找改進的餘地。最後，第三種情況。開發人員決定既不採用我們的實踐，也不說服我們採用她的實踐。因為她將決定離開團隊。
技巧
現在除了討論編寫乾淨程式碼的好處，也是時候學習一些技巧來幫助我們實現這個目標了。正如將在以下看到的，乾淨的程式碼包含並遵循著一些方法。這些方法使程式碼更乾淨、易讀、更易於理解、更簡單。當然沒有必要實施所有的方法，實施並遵循一兩項措施就足以帶來積極的結果。
1．編寫可讀的程式碼
的確，所寫的程式碼將會機器解釋，然而這並不意味著應該忽視程式碼的可讀性和可理解性，因為在將來總會有另一個人會使用我們寫的程式碼。即使讓別人無法訪問我們的程式碼，但我們自己也可能在將來又重新拾起這些程式碼。出於這些原因，讓程式碼便於閱讀和理解是符合我們自己的利益的。那麼如何實現呢？
最簡單的方法是使用空格。在釋出程式碼之前，可以縮減程式碼，但是沒有必要讓程式碼看起來很小型化。相反，可以使用縮排、換行和空行來使程式碼結構更具可讀性。當決定採用這種方式時，程式碼的可讀性和可理解性就會顯著提高。然後，看著程式碼就可以更容易理解它了
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.讓一個函式或方法只執行一個任務
當開始編寫程式碼時，使用的函式和方法看起來就像一把瑞士軍刀，幾乎可以處理任何事情，但是很難找到一個好的命名。另外，除了編寫者，幾乎沒有人知道函式是用來做什麼的以及該如何使用它。有時我就會遇到這些問題，我在這方面做的很不好。
然後，有人提出了一個很好的建議：讓每個函式或方法只執行一個任務。這個簡單的建議改變了一切，幫助我寫出了乾淨的程式碼，至少比以前更乾淨了。從那以後，其他人終於能夠理解我的程式碼了，或者說，他們不需要像以前一樣花很多時間去讀懂程式碼了，功能和方法也變得更好理解。在相同的輸入下，總是能產生相同的輸出，而且，命名也變得容易得多。
如果你很難找到函式和方法的描述性名稱，或者需要編寫冗長的指令以便其他人可以使用，那請考慮這個建議，讓每個函式或方法只執行一個任務。如果你的功能和方法看起來像瑞士軍刀一樣無所不能，那請你執行這個方法，相信我，這種多才多藝不是一種優勢。這是一個相當不利的情況，可能會產生事與願違的結果。
附註:這種讓每一個函式或方法只執行一項任務的做法被稱為保持純函式。這種編碼實踐來自於函數語言程式設計的概念。
4.更容易遵循編碼模式
不管多麼努力地為變數、函式和方法想出有意義的名字，程式碼仍然不可能完全清晰易懂，還有一些思路需要進行解釋。問題可能不是程式碼很難理解或使用，相反，其他人可能不理解為什麼要實現這個函式或方法，或者為什麼要以特定的方式建立它。意思是，建立函式或方法的意圖還不清楚。
有時可能不得不採用非傳統的方法來解決問題，因為沒有足夠的時間來想出更好的解決方案，這也很難用程式碼來解釋。所以，通過程式碼註釋可以幫助解決這個問題，也可以幫助我們向其他人解釋為什麼寫了這個方法，為什麼要用這種特定的方式來寫，那麼其他人就不必猜測這些方法或函式的用途了。
更重要的是，當我們使用注來解釋程式碼後，其他人可能會找到一個更好的方法來解決這個問題並改進程式碼。這是有可能的，因為他們知道問題是什麼，以及期望的結果是什麼。如果不知道這些資訊，其他人就很難建立更好的解決方案，或者他們可能不會去嘗試，因為他們認為沒有必要去修改建立者自己的想法。
因此，每當自己決定使用一些快速修復或非傳統的方法時，要用註釋來解釋為什麼這麼做。最好是用一兩行註釋來解釋，而不用別人來猜測。
也就是說，我們應該只在必要的時候使用註釋，而不是解釋糟糕的程式碼。編寫無窮無盡的註釋將無助於將糟糕的程式碼轉換成乾淨的程式碼。如果程式碼不好，應該通過改進程式碼來解決這個問題，而不是新增一些如何使用它的說明。編寫乾淨的程式碼更重要。
5.保持程式碼風格一致性
當我們有自己喜歡的特定編碼方式或風格時，就會在任何地方一直使用它。但在不同的專案中使用不同的編碼風格不是一個好主意，而且也不可能很自然地回到以前的程式碼，所以仍然需要一些時間來理解在專案中使用的編碼風格。
最好的方法是選擇一套編碼方式，然後在所有的專案中堅持使用。這樣的話，回到之前的舊程式碼會變得更容易。當然，嘗試新的編碼方式是一件好事，它可以幫助我們找到更好的方法來開展工作。但是最好是在不同的實驗專案或練習上嘗試不同的編碼風格，而不是在主要專案上進行。
另外，當我們決定做一些試驗的時候，就應該嘗試多次練習，應該花時間徹底地做好。只有真正確信喜歡這種做法，並且對它感到滿意時，才應該去實施它。而且決定這樣做的時候，最好應用在所有的專案中。是的，這需要時間，這也會促使我們正確地思考。
6.檢查你的程式碼
這是最後一個技巧。不僅僅是編寫乾淨的程式碼，還要完成最後的工作，那就是需要維護乾淨程式碼。我們應該定期檢查程式碼，並試著改進它。否則，如果不審查和更新我們的舊程式碼，它很快就會過時，就像我們的裝置一樣。如果想讓程式碼保持最佳狀態，就需要定期更新它們。
對於每天使用的程式碼，情況也是如此。程式碼會變得更加複雜和混亂，所有應該避免這種情況發生，並保持程式碼乾淨。實現這一點的唯一方法是定期檢查我們的程式碼。換句話說，我們需要保持它。對於那些未來不再關心的專案來說，這可能是不必要的，但對其他的來說，維護程式碼是工作的一部分。
最後
這六種做法，可能不是影響最大的，也可能不是最重要的，但這些是經驗豐富的開發人員最常提到的，這也就是我選擇它們的原因。我希望這些實踐或技巧能夠幫助你開始編寫乾淨的程式碼。
現在，就像所有的事情一樣，最重要的是開始。所以，至少選一個技巧，然後試一試。
自己是從事了五年的前端工程師，不少人私下問我，2019年前端該怎麼學，方法有沒有？
沒錯，年初我花了一個多月的時間整理出來的學習資料，希望能幫助那些想學習前端，卻又不知道怎麼開始學習的朋友。
如果你依然在程式設計的世界裡迷茫，不知道自己的未來規劃，可以加入web前端學習交流群：731771211 裡面可以與大神一起交流並走出迷茫。新手可進群免費領取學習資料，看看前輩們是如何在程式設計的世界裡傲然前行！群裡不停更新最新的教程和學習方法（進群送web前端系統學習路線，詳細的前端專案實戰教學視訊），有想學習web前端的，或是轉行，或是大學生，還有工作中想提升自己能力的，正在學習的小夥伴歡迎加入
點選： 加入