6個小技巧教你編寫乾淨整潔的代碼

編寫乾淨的代碼並非一件容易的事。它須要用不一樣的技巧和不少的實踐。寫出一手整潔的代碼也是開發者們不斷追求的目標。

編寫乾淨代碼的好處

• 項目更容易啓動和延續
• 適合新團隊人員加入項目組
• 更加容易理解

編寫乾淨代碼的要點

• 代碼更加易讀
• 爲變量，函數和方法使用更有意義的命名
• 讓每一個函數或方法只執行一個任務
• 使用註釋進行說明（重要）
• 保持一致性
• 按期檢查您的代碼

編寫乾淨代碼的好處

讓咱們先來看看編寫乾淨代碼的一些好處。其中一個主要好處是，乾淨的代碼能夠幫助咱們最大限度地縮短閱讀和嘗試理解代碼所需的時間。凌亂的代碼會減慢任何開發人員的速度讓他的工做很難開展。代碼越混亂，開發人員須要瞭解的時間就越多。並且，若是代碼太亂，開發人員可能會思考要不要重構。

1.項目更容易啓動和延續
讓我在一個簡單的例子中證實這一點。假設咱們在很長一段時間後回到了咱們以前作的一個項目。如今，讓咱們想象一下，那時候，咱們並無編寫最乾淨的代碼，而是相反。在第一次看以後，咱們看到代碼有多糟糕和混亂。並且，咱們也已經看到從咱們中斷的地方開始是多麼困難。
所以，咱們如今必須花費更多的時間在項目上，由於咱們須要瞭解咱們以前編寫的代碼。這絕對沒有必要。咱們能夠從一開始就編寫乾淨的代碼來徹底避免它。如今，咱們必須付錢。並且，咱們的舊代碼如此混亂或糟糕，以致於咱們可能決定從頭開始。聽到這些消息後，咱們的客戶可能不會高興。
另外一方面，清潔代碼一般沒有這個問題。想象一下前面的例子，條件相反。如今，咱們以前的代碼乾淨而優雅。理解它須要多長時間？也許咱們須要閱讀代碼幾分鐘才能理解一切是如何工做的。最後，咱們編寫它已經有一段時間了。可是，此次投資將明顯小於第一種狀況。咱們的客戶甚至都不會注意到它。
這是代碼編寫的第一個好處，與咱們將要討論的技巧一致。並且，這不只適用於咱們本身的項目，也適用於其餘開發人員的工做。清潔代碼使咱們可以更快地開始。咱們或其餘任何人都不須要花費數小時來研究它。相反，咱們能夠直接進入工做。

2.更適合新的團隊人員入職
編寫乾淨代碼的另外一個好處與第一個密切相關。它容許更容易和更快地採用。個人意思是這個。讓咱們想象一下，咱們須要聘請另外一位開發人員。她須要多長時間才能理解代碼並學習如何使用代碼？這取決於。若是咱們的代碼很亂而且寫得很差，她將須要更多時間來完成它。另外一方面，若是咱們的代碼乾淨，易讀，易於理解且簡單，她將可以更快地開始。

有些人可能會爭辯說，這不是一個問題，由於咱們在那裏，咱們能夠幫助她。並且，這是事實。可是，咱們的幫助應該只須要很短的時間，一兩天或三個。可是，它不該該是一週或兩三個。最後，咱們決定聘請另外一位開發人員來加快咱們的工做，而不是讓它慢下來。咱們的目標是經過幫助她學習使用咱們的代碼來消磨更多時間。

當咱們努力並編寫乾淨的代碼時，其餘人更容易遵循它並使用它。固然，咱們仍然須要留出一些時間來幫助每一個新開發人員瞭解和理解咱們的代碼。可是，咱們談論的是幾天，而不是幾周。此外，乾淨的代碼將幫助咱們爲團隊帶來更多的開發人員，並幫助他們當即理解咱們的代碼。簡而言之，代碼越清晰，解釋就越容易，誤解就越少。

3.更容易理解
咱們須要記住一件事。瞭解和學習如何使用代碼是一回事。可是，這只是一個開始。咱們還須要確保開發人員可以並願意遵循咱們的編碼實踐。一樣，使用乾淨的代碼更容易實現，而不是凌亂。這很重要，由於咱們不只要編寫乾淨的代碼，並且要保持這種方式，不管有多少人使用它。咱們須要長遠思考。

最後一件事與此有關。若是咱們的某個開發人員決定不遵循當前的編碼實踐，該怎麼辦？這個問題一般能夠解決。假設咱們有一羣人在同一個代碼庫上工做，一我的開始偏離標準風格。而後，這三件事之一將會發生。首先，該小組的其餘成員將推進一位開發人員遵循標準。她會接受它，由於她不想離開。

第二種選擇是開發人員實際上會說服團隊的其餘成員採用並遵循她的編碼實踐。若是開發人員提出的編碼實踐更清晰而且帶來更好的結果，這多是一件好事。編寫和保持咱們的代碼清潔並不意味着咱們應該忽略任何改進它的機會。偏偏相反。我認爲，咱們應該始終質疑咱們目前的作法，並尋找這些改進的機會。

所以，若是一個開發人員偏離咱們的作法，而且她的作法更好，那麼若是咱們作出改變而不是她，可能會更好。我認爲在咱們檢查和嘗試以前，咱們毫不應該忽視某人的作法。老是有改進的餘地，咱們應該繼續尋找它。最後，還有第三種選擇。開發商將決定既不採用咱們的作法也不說服咱們採用她的作法。相反，她可能會定離開團隊。

編寫乾淨代碼的提示

1.使代碼對人們可讀
確實，咱們編寫的代碼將由機器解釋。可是，這並不意味着咱們應該忽視其可讀性和可理解性。老是有可能另外一我的會接觸咱們的代碼，或者必須使用它。即便咱們讓其餘人沒法訪問咱們的代碼，咱們也可能但願未來再回到它。出於這個緣由，以一種易於理解的方式編寫代碼符合咱們本身的利益。怎麼樣？

最簡單的方法是使用空格。咱們能夠在發貨以前縮小咱們的代碼。可是，沒有必要編寫看起來像縮小的代碼。相反，咱們可使用縮進，換行符和空行來使代碼結構更具可讀性。當咱們決定接受這種作法時，咱們的代碼的可讀性和可理解性能夠顯着提升。而後，單獨查看咱們的代碼就足以理解它了。咱們來看看兩個簡單的例子。

// 很差的習慣
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']}];

// 好的作法
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'
    ]
  }
];

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.使用註釋進行說明
有個段子是這麼說的開發人員最討厭的一件事就是本身寫註釋和別人不寫註釋
不管咱們如何努力爲咱們的變量，函數和方法提出有意義的名稱並不重要。咱們的代碼自己仍然沒有儘量乾淨和易於理解。仍有一些行須要進一步解釋。問題可能不是他們難以理解或使用。相反，爲何咱們實現這個或那個功能或方法或爲何咱們以特定的方式建立它可能沒有意義。意思是，歷史還不清楚。

有時咱們可能不得不使用至關很是規的方法來解決問題，由於沒有別的方法可行，或者咱們沒有足夠的時間來提出更好的解決方案。這可能很難用代碼來解釋。經過咱們的代碼使用註釋能夠幫助咱們解決這個問題。評論能夠幫助咱們向其餘人解釋爲何咱們寫了咱們寫的東西，以及爲何咱們以特定的方式編寫它。結果，其餘人沒必要猜想。

更重要的是，當咱們解釋緣由時，其餘人可能會找到更好的方法來解決問題並改進代碼。這是可能的，由於他們知道問題是什麼以及指望的結果是什麼。在不知道這些信息的狀況下，其餘人更難以建立更好的解決方案。或者，他們甚至可能不會嘗試，由於他們認爲不須要它。他們能夠認爲這是咱們的意圖。

所以，每當咱們發現本身處於決定使用某種黑客攻擊，快速修復或很是規方法的狀況時，讓咱們使用註釋來解釋咱們爲何作了咱們所作的事情。最好使用一行或兩行做爲解釋註釋，而不是強迫人們猜想。

話雖如此，咱們應該只在必要時使用註釋，而不是解釋錯誤的代碼。編寫無窮無盡的註釋行不會幫助咱們將編寫糟糕的代碼轉換爲乾淨的代碼。若是代碼很差，咱們應該經過改進代碼來解決問題，而不是經過添加關於如何使用它的指令來解決問題。清除代碼優先於使用快捷方式。

5.保持一致
當咱們找到咱們喜歡的特定編碼實踐或風格時，咱們應該堅持並隨處使用它。在不一樣的項目中使用不一樣的編碼實踐或風格並非一個好主意。它幾乎和不使用任何編碼實踐或風格同樣有用和有用。回到咱們的舊代碼將不會像它可能那樣平滑和天然。咱們仍然須要一些時間來理解咱們在該項目中使用的編碼實踐，而後才能使用它。

最好的辦法是選擇一套編碼實踐，而後在全部項目中堅持這些實踐。而後，返回咱們的舊代碼將更容易，並繼續咱們中斷或改進它。實驗怎麼樣？嘗試新的編碼實踐是一件好事。它能夠幫助咱們找到更好的方法來完成咱們的工做。可是，最好在不一樣的實驗項目或練習上試驗不一樣的實踐，而不是咱們的主要項目。

此外，當咱們決定作一些實驗時，咱們應該屢次嘗試這種作法，並嘗試多個例子。咱們應該花時間完全作這個實驗。只有當咱們確信咱們喜歡這種作法而且咱們對此感到滿意時，咱們才應該實施它。並且，當咱們決定這樣作時，最好在咱們的全部項目中全球實施咱們的新實踐。是的，這須要時間，但這會迫使咱們適當地考慮變化。

6.按期檢查您的代碼
這是我編寫乾淨代碼的最後一個提示。簡單地編寫乾淨的代碼並非一切。咱們的工做不是用最後的分號完成的。下一步是保持咱們的代碼清潔。清潔代碼須要維護。當咱們寫東西時，咱們應該按期檢查，清理它並嘗試改進它。不然，若是咱們不審查和更新咱們的舊代碼，它很快就會過期。就像咱們的設備同樣。若是咱們想讓它們保持最佳狀態，咱們須要按期更新它們。

對於咱們天天使用的代碼，狀況尤爲如此。代碼隨着時間的推移變得愈來愈複雜和混亂，而不是更簡單和更清潔。咱們有責任防止這種狀況發生並保持咱們的代碼清潔。實現這一目標的惟一方法是按期檢查咱們的代碼。換句話說，咱們須要維護它。對於咱們再也不關心或沒有將來的項目，這可能不是必需的。對於其餘人來講，維護是咱們工做的一部分。

寫在最後

咱們在本文的最後。咱們今天討論的這六種作法可能不是影響最大或影響最大的那些。可是，它們是經驗豐富的開發人員最常提到的那些。這就是我選擇它們的緣由。我但願這些實踐或技巧足以幫助您開始編寫乾淨的代碼。如今，和全部事情同樣，最重要的是開始。因此，選擇至少一種作法並嘗試一下。

很是感謝您的寶貴時間。有一個美好的一天！