介： 和大家一起探討一下優雅代碼

一、好代碼的定義

談到好代碼，我的第一想法就是優雅，那我們如何該寫出好的代碼，讓閱讀的人感受到優雅呢？首先簡單探討一下優雅代碼的定義

關于好代碼的定義，各路大神都給出了自己的定義和見解

• 整潔的代碼如同優美的散文。—— Grady Booch
• 任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優秀的程序員。—— Martin Fowler

首先要達成一致，我們寫的代碼，除了用于機器執行產生我們預期的效果之外，更多的時候是給人讀的，可能是后續的維護人員，更多時候是一段時間后的作者本人，因此優雅面向不同的用戶有兩層含義的解讀

1. 對人而言，代碼的整潔，清晰的邏輯
2. 對機器而言，準確性、執行性能、異常處理機制等

這次，我們就來聊一聊，什么代碼是優雅的代碼，怎樣寫出優雅的代碼

二、代碼整潔

1. 有意義的命名

簡單說就是類、方法、變量的命名要名副其實，要能描述清晰自己的職責。一個好的命名能輸出更多的信息，它會告訴你，它為什么存在，它是做什么事的，應該怎么使用。一個簡單的衡量標準是，如果命名完仍需要注釋來補充語義，那就不是名副其實；

選個好名字要花時間，但省下的時間的時間比花掉的多，一旦發現有更好的名稱，就換掉舊的。

舉個栗子

public List<int[]> getItem() {
    List<int[]> list1=new ArrayList<int[]>();
    for (int[] x: theList)
        if (x[0]==4)
            list1.add(x);
    return list1;
}

整體邏輯沒啥問題，讀完之后，就有很多問題在腦海中產生

• 1. theList中是存儲什么東西的數組？
• 2. theList第一個值是做什么的？
• 3. 值4的意義又是什么？
• 4. 返回的列表該怎么使用？

代碼應該體現所處的情景，比方說上述的代碼所處情景是我們正在開發一種掃雷游戲，盤面是名為theList的單元格列表，那就將其名稱改為gameBoard。

盤面上每個單元格都用一個簡單數組表示。零下標條目是一種狀態值，而這種狀態值為4代表“已標記”。只要改為有意義的名稱，代碼就得到了改進。

更進一步，不用int數組來表示單元格，而是另寫一個類。該類包括一個名副其實的函數（稱為isFlagged），從而掩蓋住哪個魔術數4，得到新的函數版本。

public List<Cell> getFlaggedCells() {
  List<Cell> flaggedCells=new ArrayList<Cell>();
  for (Cell cell : gameBoard)
    if (cell.isFlagged())
      flaggedCells.add(cell);
  return flaggedCells;
}

2. 優雅的注釋

實際上，只要我們的代碼有足夠的表達力，能清晰的通過命名來做到名副其實，就不太需要注釋，或者根本不需要；注釋的存在往往是彌補我們無法用代碼清晰表達意圖的情況。可以想象一下，每次自己發現需要寫注釋的時候，是什么心態，擔心此處代碼明天自己看不懂或者別人看不懂，那有沒有考慮用更好的語義的代碼來替代。

但盡管有注釋，也有好有壞，有時候注釋也會撒謊，通常注釋存在的越久，就離其描述的代碼越遠，變得越來越離譜；因為代碼在變動在迭代，在注釋和代碼間可能會插入新的代碼，舊代碼我們通常copy來copy去，分離又重組，但注釋一般不會修改，就會造成注釋和描述的代碼分離，對閱讀者造成更大的迷惑。

我們在需要寫注釋的時候就要告訴自己，能不能用代碼來進行描述。以下是一些壞代碼的注釋bad case

1. 一些被注釋掉的代碼
//something code
//something code
2. 位置標記
//begin
someting code;
//end
3. 簽名標記
/** add by xiaoli*/
4. 非公用方法的javadoc
/**
* doSomething
*/
private void doSomething(){
}
5. 日志式注釋
/** add xx
* update sometimes
* update sometimes
* update sometimes
*/
6. 誤導性注釋
//此處怎樣xx

3. 優雅的函數

3.1 務必要短小

方法應該有多短小？沒有明確約束，idea也不會限制你，但通常我們的方法不該長于一屏，至少多于一屏或者橫向外溢到屏幕以外最直觀的就會造成可讀性體驗差，讀了下面忘記上面，左右拖拽等。對大多數筆記本來說一屏大概就30行左右。短小精簡的方法要比30行短很多，比如

public String renderPageWithSetupAndTeardowns(Page page, boolean isSuite) throws Exception{
  if(isTestPage(page)){
        includeSetupAndTeardownPages(page,isSuite);
    }
    return page.getHtml();
}

if語句、else語句、while語句等，其中的代碼應該只有一行，

改行通常是一個調用語句，這樣不但能保持短小，還可以給調用方法命名一個有說明性的名字，進一步增加代碼的可讀性

3.2 只做一件事

一事精，便可動人。這個普世法則甚至適用于各種場合。像設計原則的單一職責模式，讓類只有一個職責。如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致邏輯混亂，設計耦合。當一個職責發生變化時，可能會影響其它的職責。

另外，多個職責耦合在一起，會影響復用性。針對方法而言更是如此。方法作為程序的原子單元，保持單一會有效提升復用性。 那怎么判斷一個方法是否只做了一件事。最簡單的規則就是看看該方法是否能在拆出一個方法，且拆出去的方法是不同于該方法的詮釋和實現。但是要注意同一方法的邏輯層級務必要一致。

3.3 抽象層級一致

抽象層級一致也是對方法只做一件事的更高要求，抽象層級不一致的代碼一定是做了多件事。

我們讀代碼通常是自頂向下閱讀，我們想讓每個方法后面都跟著位于下一層級的方法，這樣我們可以依著抽象層級向下閱讀了。我們也需要這樣閱讀代碼，先有整體在展示細節，這種叫向下規則。這也是保持方法短小，確保只做一件事的訣竅。一旦方法中混雜不同的抽象層級，會讓人很迷惑，因為沒辦法這個方法中判斷某個表達式是基礎概念還是細節，更惡劣的是，一旦細節與基礎概念混雜，更多的細節就會糾纏不清，舉例子我們想寫一個冰凍大象的需求

//把大象裝進冰箱
public void frozenElephant(){
    //1. 捕捉大象
    //2. 運輸大象
    //3. 打開冰箱
    //4. 放入大象
    //5. 關閉冰箱
}

這個例子的1.2兩步就不是一個層級的邏輯，是屬于更高層級的抽象。3.4.5都是將大象放入冰箱的步驟，屬于低層級的抽象。可以將代碼拆分為如下實現，將高抽象層級的代碼聚合提取出來，細節在分別單獨實現，如下

public void frozenElephant(){
    //1. 捕捉大象
    catchElephant();
    //2. 運輸大象
    transportElephant();
    //將大象放入冰箱
    putElephantInRefrigerator();
}
public void catchElephant(){
}
public void transportElephant(){
}
public void putElephantInRefrigerator(){
    //打開冰箱
    //放入大象
    //關閉冰箱
}

3.4 使用異常替代返回錯誤碼

針對錯誤碼的判斷會導致更深層次的嵌套結構，返回錯誤碼就意味著要求調用者跟著處理錯誤，如下

if(deletePage()==OK){
    if(registry.deleteReference(page.name)==OK){
        if(configKeys.deleteKey(page.name.makeKey)==OK){
            logger.log("page deleted")
        }else{
            logger.log("configKey not deleted")
        }
    }else{
        logger.log("deleteReference from registry failed")
    }
}else{
    logger.log("delete failed")
    return Error;
}

一般我們還需要將try/Catch代碼塊給抽離出去，另外形成方法。防止代碼塊過多搞亂代碼結構，分不清錯誤處理還是正常流程。同時因為方法只做一件事，錯誤處理就是一件事，因此錯誤處理的方法不應該在做其他事，也就是如果一個方法中有try關鍵字，那try就是方法的開頭。catch/finally代碼塊后面也不應該再有內容，如下

try{
    deletePage(page);
    registry.deleteReference(page.name);
    configKeys.deleteKey(page.name.makeKey);
}catch(Exception e){
    logger.log(e.getMessage());
}

3.5 使用第三方庫

比如Lombok組件通過注解的方式，在編譯時自動為屬性生成構造器、getter/setter、equals、hashcode、toString方法 舉例如下：

比如Apache Commons系列組件給我們提供了關于字符串、集合、IO操作等工具方法。這些組件是個大寶庫，提供了不少輪子

三、代碼重構

重構是對軟件內部結構的一種調整，目的是在不改變軟件可觀察行為的前提下，提高其可理解性，降低其修改成本。

在重構之前一定要知道，一旦開始對類和方法進行重構，就需要事前有完備的單元測試用例來保障重構的準確性，每次重構之后都要去執行對應的單元測試用例，驗證重構的正確性！

1. 識別代碼的壞味道

1.1 重復的代碼

如果在一個以上的地點看到相同的代碼結構，可以肯定的是，想辦法抽線出來合而為一，代碼會變得更好。一般包含幾個點的重復

1. 最單純的重復代碼就是“同一個類的兩個函數含有相同的表達式”。這時候需要做的就是采用提煉函數提煉出重復的代碼，然后讓這兩個地點都調用被提煉出來的那一段代碼
2. 如果重復代碼只是相似而不是完全相同，需要先嘗試用移動語句重組代碼順序，把相似的部分放在一起以便提煉。
3. 如果重復的代碼段位于同一個超類的不同子類中，可以使用函數上移來避免在兩個子類之間互相調用。

1.2 過長的函數

遵循這樣一條原則：每當感覺需要以注釋來說明點什么的時候，就把需要說明的東西寫進一個獨立函數中，并以其用途（而非實現手法）命名，可以對一組甚至短短一行代碼做這件事。哪怕替換后的函數調用動作比函數自身還長，只要函數名稱能夠解釋其用途，就要毫不猶豫地那樣做，關鍵不在于函數的長度，而在于函數“做什么”和“如何做”之間的語義距離。

1. 百分之九十九的場合里，要把函數變短，只需使用提煉函數。找到函數中適合集中在一起的部分，將它們提煉出來形成一個新函數。
2. 如果函數內有大量的參數和臨時變量，最終就會把許多參數傳遞給被提煉出來的新函數，導致可讀性幾乎沒有任何提升。此時可以經常運用以查詢取代臨時變量來消除這些臨時元素。引入參數對象和保持對象完整則可以將過長的參數列表變得更簡潔一些。
3. 如果有多個switch語句基于同一個條件 進行分支選擇，就應該使用以多態取代條件表達式。

1.3 數據的可變性

對數據的修改經常導致出乎意料的結果和難以發現的bug。在一處更新數據，卻沒有意識到軟件中的另一處期望著完全不同的數據，于是出現難以預料的bug，往往比較難排查（需要排查數據流轉的整體鏈路），這就需要一些方法用于約束對數據的更新，降低數據可變性的風險。

1. 可以用封裝變量來確保所有數據更新操作都通過很少幾個函數來進行，使其更容易統一監控和演進
2. 如果一個變量在不同時候被用于存儲不同的東西， 可以使用拆分變量將其拆分為各自不同用途的變量，從而避免危險的更新操作。
3. 使用移動和提煉函數盡量把邏輯從處理更新操作的代碼中搬移出來，將業務處理邏輯代碼與執行數據更新操作的代碼分開。

1.4 模塊單一職責

所謂模塊化，就是力求將代碼分出區域，最大化區域內部的交互、最小化跨區域的交互。但是經常出現一個函數跟另一個模塊中的函數或者數據交流格外頻繁，遠勝于與所處模塊內部的交流，這就是模塊功能不單一的典型情況。

1. 總看到某個函數為了計算某個值，從另一個對象那兒調用半打的取值函數。如果這個函數需要跟這些數據待在一起，那就使用移動功能把它移過去。
2. 一個函數往往會用到幾個模塊的功能，那么它究竟該被置于何處呢？原則是：判斷哪個模塊擁有的此函數使用的數據最多，然后就把這個函數和那些數據擺在一起。 如果先以提煉函數將這個函數分解為數個較小的函數并分別置放于不同類中，上面的步驟就會比較容易完成。
3. Strategy模式和Visitor模式是為了對抗發散式變化，但也能解決單一職責問題，最根本的原則是：將總是一起變化的東西放在一塊兒。 數據和引用這些數據的行為總是一起變化的，如果有特殊情況，我們就搬移那些行為，保持變化始終只在一地發生。

點擊查看原文，獲取更多福利！

https://developer.aliyun.com/article/1117703?utm_content=g_1000366324

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

C語言中，if語句是一種常用的選擇結構語句，用于根據條件選擇性地執行不同的代碼塊。if語句的設計使得程序可以根據條件的真假進行分支控制，從而實現靈活的程序邏輯。本文將深入介紹C語言中如何使用if語句設計選擇結構程序，包括if語句的語法、使用方法、常見應用場景以及注意事項，以幫助讀者更好地理解和運用這一重要的編程概念。

以下是我整理的關于C語言的一些入門級資料，免費分享給大家：https://m.hqyjai.net/emb_study_blue_short.html?xt=zxy

開發中，變量名，函數名一般要做到清晰明了，盡量做到看名字就能讓人知道你的意圖，所以變量和函數命名是挺重要，今天來看看如果較優雅的方式給變量和函數命名。

一、變量

使用有意義和可發音的變量名

// 不好的寫法 const yyyymmdstr = moment().format("YYYY/MM/DD");  // 好的寫法 const currentDate = moment().format("YYYY/MM/DD"); 

對同一類型的變量使用相同的詞匯

// 不好的寫法 getUserInfo(); getClientData(); getCustomerRecord();  // 好的寫法 getUser(); 

使用可搜索的名字

我們讀的會比我們寫的多得多，所以如果命名太過隨意不僅會給后續的維護帶來困難，也會傷害了讀我們代碼的開發者。讓你的變量名可被讀取，像 buddy.js 和 ESLint 這樣的工具可以幫助識別未命名的常量。

// 不好的寫法 // 86400000 的用途是什么？ setTimeout(blastOff, 86400000);  // 好的寫法 const MILLISECONDS_IN_A_DAY = 86_400_000; setTimeout(blastOff, MILLISECONDS_IN_A_DAY); 

使用解釋性變量

// 不好的寫法 const address = "One Infinite Loop, Cupertino 95014"; const cityZipCodeRegex = /^[^,\]+[,\\s]+(.+?)\s*(\d{5})?$/; saveCityZipCode(   address.match(cityZipCodeRegex)[1],   address.match(cityZipCodeRegex)[2] );   // 好的寫法 const address = "One Infinite Loop, Cupertino 95014"; const cityZipCodeRegex = /^[^,\]+[,\\s]+(.+?)\s*(\d{5})?$/; const [_, city, zipCode] = address.match(cityZipCodeRegex) || []; saveCityZipCode(city, zipCode); 

避免費腦的猜測

顯式用于隱式

// 不好的寫法 const locations = ["Austin", "New York", "San Francisco"]; locations.forEach(l => {   doStuff();   doSomeOtherStuff();   // ...   // ...   // ...   // 等等，“l”又是什么？   dispatch(l);  // 好的寫法 const locations = ["Austin", "New York", "San Francisco"]; locations.forEach(location => {   doStuff();   doSomeOtherStuff();   // ...   // ...   // ...   dispatch(location); }); 

無需添加不必要的上下文

如果類名/對象名已經說明了，就無需在變量名中重復。

// 不好的寫法 const Car = {   carMake: "Honda",   carModel: "Accord",   carColor: "Blue" };  function paintCar(car) {   car.carColor = "Red"; } // 好的寫法 const Car = {   make: "Honda",   model: "Accord",   color: "Blue" };  function paintCar(car) {   car.color = "Red"; } 

使用默認參數代替邏輯或(與)運算

// 不好的寫法 function createMicrobrewery(name) {   const breweryName = name || "Hipster Brew Co.";   // ... } // 好的寫法 function createMicrobrewery(name = "Hipster Brew Co.") {   // ... } 

二、函數

函數參數(理想情況下為2個或更少)

限制函數參數的數量是非常重要的，因為它使測試函數變得更容易。如果有三個以上的參數，就會導致組合爆炸，必須用每個單獨的參數測試大量不同的情況。

一個或兩個參數是理想的情況，如果可能，應避免三個參數。除此之外，還應該合并。大多數情況下，大于三個參數可以用對象來代替。

// 不好的寫法 function createMenu(title, body, buttonText, cancellable) {   // ... }  createMenu("Foo", "Bar", "Baz", true);  // 好的寫法 function createMenu({ title, body, buttonText, cancellable }) {   // ... }  createMenu({   title: "Foo",   body: "Bar",   buttonText: "Baz",   cancellable: true }); 

函數應該只做一件事

這是目前為止軟件工程中最重要的規則。當函數做不止一件事時，它們就更難組合、測試和推理。可以將一個函數隔離為一個操作時，就可以很容易地重構它，代碼也會讀起來更清晰。

// 不好的寫法 function emailClients(clients) {   clients.forEach(client => {     const clientRecord = database.lookup(client);     if (clientRecord.isActive()) {       email(client);     }   }); }  // 好的寫法  function emailActiveClients(clients) {   clients.filter(isActiveClient).forEach(email); }  function isActiveClient(client) {   const clientRecord = database.lookup(client);   return clientRecord.isActive(); } 

函數名稱應說明其作用

// 不好的寫法 function addToDate(date, month) {   // ... }  const date = new Date();  // 從函數名稱很難知道添加什么 addToDate(date, 1);  // 好的寫法 function addMonthToDate(month, date) {   // ... }  const date = new Date(); addMonthToDate(1, date); 

函數應該只有一個抽象層次

當有一個以上的抽象層次函數，意味該函數做得太多了，需要將函數拆分可以實現可重用性和更簡單的測試。

// 不好的寫法 function parseBetterJSAlternative(code) {   const REGEXES = [     // ...   ];    const statements = code.split(" ");   const tokens = [];   REGEXES.forEach(REGEX => {     statements.forEach(statement => {       // ...     });   });    const ast = [];   tokens.forEach(token => {     // lex...   });    ast.forEach(node => {     // parse...   }); }  // 好的寫法 function parseBetterJSAlternative(code) {   const tokens = tokenize(code);   const syntaxTree = parse(tokens);   syntaxTree.forEach(node => {     // parse...   }); }  function tokenize(code) {   const REGEXES = [     // ...   ];    const statements = code.split(" ");   const tokens = [];   REGEXES.forEach(REGEX => {     statements.forEach(statement => {       tokens.push(/* ... */);     });   });    return tokens; }  function parse(tokens) {   const syntaxTree = [];   tokens.forEach(token => {     syntaxTree.push(/* ... */);   });    return syntaxTree; } 

刪除重復的代碼

盡量避免重復的代碼，重復的代碼是不好的，它意味著如果我們需要更改某些邏輯，要改很多地方。

通常，有重復的代碼，是因為有兩個或多個稍有不同的事物，它們有很多共同點，但是它們之間的差異迫使我們編寫兩個或多個獨立的函數來完成許多相同的事情。 刪除重復的代碼意味著創建一個僅用一個函數/模塊/類就可以處理這組不同事物的抽象。

獲得正確的抽象是至關重要的，這就是為什么我們應該遵循類部分中列出的 「SOLID原則」。糟糕的抽象可能比重復的代碼更糟糕，所以要小心!說了這么多，如果你能做一個好的抽象，那就去做吧!不要重復你自己，否則你會發現自己在任何時候想要改變一件事的時候都要更新多個地方。

「設計模式的六大原則有」

• Single Responsibility Principle：單一職責原則
• Open Closed Principle：開閉原則
• Liskov Substitution Principle：里氏替換原則
• Law of Demeter：迪米特法則
• Interface Segregation Principle：接口隔離原則
• Dependence Inversion Principle：依賴倒置原則

把這六個原則的首字母聯合起來(兩個 L 算做一個)就是 SOLID (solid，穩定的)，其代表的含義就是這六個原則結合使用的好處：建立穩定、靈活、健壯的設計。下面我們來分別看一下這六大設計原則。

「不好的寫法」

function showDeveloperList(developers) {   developers.forEach(developer => {     const expectedSalary = developer.calculateExpectedSalary();     const experience = developer.getExperience();     const githubLink = developer.getGithubLink();     const data = {       expectedSalary,       experience,       githubLink     };      render(data);   }); }  function showManagerList(managers) {   managers.forEach(manager => {     const expectedSalary = manager.calculateExpectedSalary();     const experience = manager.getExperience();     const portfolio = manager.getMBAProjects();     const data = {       expectedSalary,       experience,       portfolio     };      render(data);   }); } 

「好的寫法」

function showEmployeeList(employees) {   employees.forEach(employee => {     const expectedSalary = employee.calculateExpectedSalary();     const experience = employee.getExperience();      const data = {       expectedSalary,       experience     };      switch (employee.type) {       case "manager":         data.portfolio = employee.getMBAProjects();         break;       case "developer":         data.githubLink = employee.getGithubLink();         break;     }      render(data);   }); } 

使用Object.assign設置默認對象

「不好的寫法」

const menuConfig = {   title: null,   body: "Bar",   buttonText: null,   cancellable: true };  function createMenu(config) {   configconfig.title = config.title || "Foo";   configconfig.body = config.body || "Bar";   configconfig.buttonText = config.buttonText || "Baz";   configconfig.cancellable =     config.cancellable !== undefined ? config.cancellable : true; }  createMenu(menuConfig); 

「好的寫法」

const menuConfig = {   title: "Order",   // User did not include 'body' key   buttonText: "Send",   cancellable: true };  function createMenu(config) {   config = Object.assign(     {       title: "Foo",       body: "Bar",       buttonText: "Baz",       cancellable: true     },     config   );    // config now equals: {title: "Order", body: "Bar", buttonText: "Send", cancellable: true}   // ... }  createMenu(menuConfig); 

不要使用標志作為函數參數

標志告訴使用者，此函數可以完成多項任務，函數應該做一件事。如果函數遵循基于布爾的不同代碼路徑，請拆分它們。

// 不好的寫法 function createFile(name, temp) {   if (temp) {     fs.create(`./temp/${name}`);   } else {     fs.create(name);   } }  // 好的寫法 function createFile(name) {   fs.create(name); }  function createTempFile(name) {   createFile(`./temp/${name}`); } 

避免副作用(第一部分)

如果函數除了接受一個值并返回另一個值或多個值以外，不執行任何其他操作，都會產生副作用。副作用可能是寫入文件，修改某些全局變量，或者不小心將你的所有資金都匯給了陌生人。

「不好的寫法」

let name = "Ryan McDermott";  function splitIntoFirstAndLastName() {   namename = name.split(" "); }  splitIntoFirstAndLastName();  console.log(name); // ['Ryan', 'McDermott']; 

「好的寫法」

function splitIntoFirstAndLastName(name) {   return name.split(" "); }  const name = "Ryan McDermott"; const newName = splitIntoFirstAndLastName(name);  console.log(name); // 'Ryan McDermott'; console.log(newName); // ['Ryan', 'McDermott']; 

避免副作用(第二部分)

在JavaScript中，原始類型值是按值傳遞，而對象/數組按引用傳遞。對于對象和數組，如果有函數在購物車數組中進行了更改(例如，通過添加要購買的商品)，則使用該購物車數組的任何其他函數都將受到此添加的影響。那可能很棒，但是也可能不好。來想象一個糟糕的情況：

用戶單擊“購買”按鈕，該按鈕調用一個purchase 函數，接著，該函數發出一個網絡請求并將cart數組發送到服務器。由于網絡連接不好，purchase函數必須不斷重試請求。現在，如果在網絡請求開始之前，用戶不小心點擊了他們實際上不需要的項目上的“添加到購物車”按鈕，該怎么辦?如果發生這種情況，并且網絡請求開始，那么購買函數將發送意外添加的商品，因為它有一個對購物車數組的引用，addItemToCart函數通過添加修改了這個購物車數組。

一個很好的解決方案是addItemToCart總是克隆cart數組，編輯它，然后返回克隆。這可以確保購物車引用的其他函數不會受到任何更改的影響。

關于這種方法有兩點需要注意：

• 可能在某些情況下，我們確實需要修改輸入對象，但是當我們采用這種編程實踐時，會發現這種情況非常少見，大多數東西都可以被改造成沒有副作用。
• 就性能而言，克隆大對象可能會非常昂貴。幸運的是，在實踐中這并不是一個大問題，因為有很多很棒的庫使這種編程方法能夠快速進行，并且不像手動克隆對象和數組那樣占用大量內存。

// 不好的寫法 const addItemToCart = (cart, item) => {   cart.push({ item, date: Date.now() }); };  // 好的寫法 const addItemToCart = (cart, item) => {   return [...cart, { item, date: Date.now() }]; }; 

不要寫全局函數

污染全局變量在 JS 中是一種不好的做法，因為可能會與另一個庫發生沖突，并且在他們的生產中遇到異常之前，API 的用戶將毫無用處。讓我們考慮一個示例：如果想擴展 JS 的原生Array方法以具有可以顯示兩個數組之間差異的diff方法，該怎么辦?可以將新函數寫入Array.prototype，但它可能與另一個嘗試執行相同操作的庫發生沖突。如果其他庫僅使用diff來查找數組的第一個元素和最后一個元素之間的區別怎么辦?這就是為什么只使用 ES6 類并簡單地擴展Array全局會更好的原因。

// 不好的寫法 Array.prototype.diff = function diff(comparisonArray) {   const hash = new Set(comparisonArray);   return this.filter(elem => !hash.has(elem)); };  // 好的寫法 class SuperArray extends Array {   diff(comparisonArray) {     const hash = new Set(comparisonArray);     return this.filter(elem => !hash.has(elem));   } } 

盡量使用函數式編程而非命令式

JavaScript不像Haskell那樣是一種函數式語言，但它具有函數式的風格。函數式語言可以更簡潔、更容易測試。如果可以的話，盡量喜歡這種編程風格。

「不好的寫法」

const programmerOutput = [   {     name: "Uncle Bobby",     linesOfCode: 500   },   {     name: "Suzie Q",     linesOfCode: 1500   },   {     name: "Jimmy Gosling",     linesOfCode: 150   },   {     name: "Gracie Hopper",     linesOfCode: 1000   } ];  let totalOutput = 0;  for (let i = 0; i < programmerOutput.length; i++) {   totalOutput += programmerOutput[i].linesOfCode; } 

「好的寫法」

const programmerOutput = [   {     name: "Uncle Bobby",     linesOfCode: 500   },   {     name: "Suzie Q",     linesOfCode: 1500   },   {     name: "Jimmy Gosling",     linesOfCode: 150   },   {     name: "Gracie Hopper",     linesOfCode: 1000   } ];  const totalOutput = programmerOutput.reduce(   (totalLines, output) => totalLines + output.linesOfCode,   0 ); 

封裝條件

// 不好的寫法 if (fsm.state === "fetching" && isEmpty(listNode)) {   // ... }  // 好的寫法 function shouldShowSpinner(fsm, listNode) {   return fsm.state === "fetching" && isEmpty(listNode); }  if (shouldShowSpinner(fsmInstance, listNodeInstance)) {   // ... } 

避免使用非條件

// 不好的寫法 function isDOMNodeNotPresent(node) {   // ... }  if (!isDOMNodeNotPresent(node)) {   // ... }  // 好的寫法 function isDOMNodePresent(node) {   // ... }  if (isDOMNodePresent(node)) {   // ... } 

避免使用過多條件

這似乎是一個不可能完成的任務。一聽到這個，大多數人會說，“沒有if語句，我怎么能做任何事情呢?”答案是，你可以在許多情況下使用多態性來實現相同的任務。

第二個問題通常是，“那很好，但是我為什么要那樣做呢?”答案是上面講過一個概念:一個函數應該只做一件事。當具有if語句的類和函數時，這是在告訴你的使用者該函數執行不止一件事情。

「不好的寫法」

class Airplane {   // ...   getCruisingAltitude() {     switch (this.type) {       case "777":         return this.getMaxAltitude() - this.getPassengerCount();       case "Air Force One":         return this.getMaxAltitude();       case "Cessna":         return this.getMaxAltitude() - this.getFuelExpenditure();     }   } } 

「好的寫法」

class Airplane {   // ... }  class Boeing777 extends Airplane {   // ...   getCruisingAltitude() {     return this.getMaxAltitude() - this.getPassengerCount();   } }  class AirForceOne extends Airplane {   // ...   getCruisingAltitude() {     return this.getMaxAltitude();   } }  class Cessna extends Airplane {   // ...   getCruisingAltitude() {     return this.getMaxAltitude() - this.getFuelExpenditure();   } } 

避免類型檢查

JavaScript 是無類型的，這意味著函數可以接受任何類型的參數。有時q我們會被這種自由所困擾，并且很想在函數中進行類型檢查。有很多方法可以避免這樣做。首先要考慮的是一致的API。

// 不好的寫法 function travelToTexas(vehicle) {   if (vehicle instanceof Bicycle) {     vehicle.pedal(this.currentLocation, new Location("texas"));   } else if (vehicle instanceof Car) {     vehicle.drive(this.currentLocation, new Location("texas"));   } }  // 好的寫法 function travelToTexas(vehicle) {   vehicle.move(this.currentLocation, new Location("texas")); } 

不要過度優化

現代瀏覽器在運行時做了大量的優化工作。很多時候，如果你在優化，那么你只是在浪費時間。有很好的資源可以查看哪里缺乏優化，我們只需要針對需要優化的地方就行了。

// 不好的寫法  // 在舊的瀏覽器上，每一次使用無緩存“list.length”的迭代都是很昂貴的 // 會為“list.length”重新計算。在現代瀏覽器中，這是經過優化的 for (let i = 0, len = list.length; i < len; i++) {   // ... }  // 好的寫法 for (let i = 0; i < list.length; i++) {   // ... } 

原文：https://developer.51cto.com/art/202005/616073.htm

作者：前端小智