有一些非常常見的編程錯誤是我們要避免的，以保持代碼的干凈和可讀性。

[[327097]]

在本文中，我將研究它們以及如何避免它們。

一個函數(shù)中的東西太多

一個函數(shù)應(yīng)該只做一件事，這就是它自己所指示的。

如果有其他的東西，那么它應(yīng)該被移動到它自己的函數(shù)中，在一個函數(shù)中有太多的東西會使閱讀和理解變得困難。

例如，如果有一個既可以計算小計又可以計算稅款的函數(shù)，則由于它們是不同的，因此應(yīng)將其分為兩個單獨的函數(shù)。

注釋掉的代碼

注釋掉的代碼是不能運行的代碼。因此，在我們完成代碼的這一部分之后，它們不應(yīng)該出現(xiàn)。

完成后，我們應(yīng)該刪除已注釋掉或取消注釋。

無論哪種方式，最終產(chǎn)品都不應(yīng)在其中注釋掉代碼。

非描述性的變量名

以不傳達其含義的方式命名變量，一旦我們忘記了自己寫的那段代碼，再回來看，就會讓讀者和我們自己感到沮喪。

因此，我們應(yīng)該使用描述變量名稱的變量來命名變量。

不要寫成 let x;，而是寫成像 let numApples 這樣的東西，這樣我們就知道我們的變量將持有蘋果的數(shù)量。

魔法數(shù)字和字符串

我們不應(yīng)該有魔術(shù)數(shù)字和字符串。這些值出現(xiàn)在多個值中，表示相同的東西，但在代碼中沒有明確解釋。

例如，如果我們有以下代碼：

for (let i = 0; i < 10; i++) { 
  ///... 
} 

那我們不知道10代表什么。相反，我們應(yīng)該將其設(shè)置為命名常量，以便我們了解其含義。

例如，我們可以這樣寫：

const numApples = 10; 
for (let i = 0; i < numApples; i++) { 
  ///... 
} 

現(xiàn)在我們知道10實際上意味著蘋果的數(shù)量。

凌亂的代碼格式

凌亂的代碼格式化會使代碼難以閱讀，因此我們應(yīng)該使用lint或代碼格式化程序?qū)ζ溥M行清理。

那里有很多選擇，因此我們可以使用Prettier或ESLint這樣的工具自動進行整理。

硬編碼值

我們不應(yīng)該把值硬編碼到我們的代碼中，特別是當它們是私密的時候。相反，我們應(yīng)該把它們作為環(huán)境變量，并從那里讀取所有的值。

有很多方法可以做到這一點。例如，對于前端，Angular，React和Vue都有保留變量的位置，以將變量保存在不同文件中的不同環(huán)境中。

對于后端，我們可以使用諸如 dotenv 包之類的東西從 .env 文件中讀取環(huán)境變量，這樣我們就不必對它們進行硬編碼。

重復(fù)代碼

重復(fù)的代碼是不好的。如果我們改變一些重復(fù)的東西，就必須在所有重復(fù)的地方都要改變它們。

相反，我們應(yīng)該將公共部分移動到它們自己的文件中，以便可以在多個地方使用它們。

不重復(fù)使用(DRY)原則適用于所有地方。如果我們完全照原樣復(fù)制和粘貼并使用它們，則應(yīng)將其移動到共享位置。

不備份代碼

我們應(yīng)該使用Git管理代碼，以便我們可以為我們的代碼提供本地和遠程存儲庫。

這樣，我們可以自動將一個副本保留在遠程位置。同樣，我們可以輕松地還原錯誤代碼，并輕松地從較早的提交中獲取代碼。

沒有版本控制，我們無法做到這一點。

如果我們沒有備份代碼，那么如果出現(xiàn)問題，我們可能會丟失所有內(nèi)容。

復(fù)雜代碼

應(yīng)該簡化復(fù)雜的代碼，以便我們更容易理解它們。

我們還應(yīng)該將它們分解成較小的部分，以便我們可以重復(fù)使用某些內(nèi)容，并具有易于閱讀和測試的單個部分。

總結(jié)

這些常見的錯誤，只要我們在做事情的時候注意點，是很容易避免的。

將事物分解成小塊總是好的，就像保持事物簡單而不重復(fù)一樣。

注釋掉了，沒有描述性的變量和值也應(yīng)該用更有意義的東西代替。