在這篇文章中，我介紹了一些程式設計時嘗試使用的模式。這些模式是多年來我自己在工作中實踐的結果，也有是從同事那裡偷偷學到的。這些模式沒有特定的順序，只是一個簡單的集合。

提前退出（early exits）

function transformData(rawData) {
  // check if no data
  if (!rawData) {
    return [];
  }

  // check for specific case
  if (rawData.length == 1) {
    return [];
  }

  // actual function code goes here
  return rawData.map((item) => item);
}
 

我將這種模式稱為“提前退出（early exits）”，但有些人也將此稱為“保鏢模式（the Bouncer Pattern）”或“保護條款（'guard clauses）”。撇開命名不談，該模式採用的方法是首先檢查無效的情況，然後從該函式返回，否則它將繼續使用該函式的預期情況並執行。

對我來說，這種方法有一些我非常喜歡的優點:

1. 有助於思考無效和邊界情況，以及在這種情況下該如何處理。
2. 避免對意外情況進行意外和不必要的程式碼處理
3. 這樣使我更能清楚地處理每種情況
4. 一旦使用這種方式，您就可以快速地瀏覽函式並理解流程和執行，這通常遵循自頂向下的方法，即從無效的情況—>小情況—>預期情況。

更多資訊：保鏢模式（the Bouncer Pattern）

2. 用物件字面量替代 Switch

// Switch
let createType = null;
switch (contentType) {
  case "post":
    createType = () => console.log("creating a post...");
    break;
  case "video":
    createType = () => console.log("creating a video...");
    break;
  default:
    createType = () => console.log('unrecognized content type');
}

createType();

// Object literal
const
 
 contentTypes = {
  post: () => console.log("creating a post..."),
  video: () => console.log("creatinga  video..."),
  default: () => console.log('unrecognized content type')
};

const createType = contentTypes[contentType] || contentTypes['default'];
createType();

接下來就是要移除Switch。在寫case的時候我經常會犯錯誤，也會忘記寫break，這會引起各種有趣的問題。當我編寫程式碼時，switch語句並沒有體現太多的價值。

我更喜歡使用物件字面量，原因如下:

1. 不用擔心cace或break。
2. 更容易閱讀並快速瞭解正在發生的事情
3. 物件字面量很容易寫
4. 程式碼量少

3. 用一次迴圈處理兩個陣列

const exampleValues = [2, 15, 8, 23, 1, 32];
const [truthyValues, falseyValues] = exampleValues.reduce((arrays, exampleValue) => {
  if (exampleValue > 10) {
    arrays[0].push(exampleValue);
    return arrays;
  }

  arrays[1].push(exampleValue);
  return arrays;
}, [[], []]);

這種模式沒什麼特別的，我應該早點意識到，但我發現自己過濾一組元素，以獲得所有匹配特定條件的元素，然後在另一種情況下要再做一次。這意味著對一個數組進行兩次迴圈，但我可以只做一次。

原來它有一個名字(bifurcate)，我從30secondsofcode.org借鑑過來的。如果你從未去過那個網站，我建議你去那裡。有很多有用的資訊和程式碼。

我知道reduce可能會讓人望而生畏，也不太清楚會發生什麼，但如果你能適應它，在遍歷集合時，您可以真正利用它來構建所需的任何資料結構。他們應該叫它builder而不是reduce。

4. 不要用foo做變數

// bad
const foo = y && z;

// good
const isPostEnabled = isPost && postDateValid;

這看起來很明顯，但我相信我們都見過這樣做的程式碼。花點時間，盡你最大的努力取個合適的名字。

這對於在職的專業人士或處於教育他人位置的人來說尤其重要。應該使用變數命名來幫助解釋，在程式碼的上下文中發生了什麼事情。

別人能夠在閱讀您的程式碼時，並大致可以理解要解決的問題。

更多資訊：The art of naming variables

PPT模板下載大全https://www.wode007.com

5. 巢狀三元運算子

// 之前
let result = null;
if (conditionA) {
  if (conditionB) {
    result = "A & B";
  } else {
    result = "A";
  }
} else {
  result = "Not A";
}
// 改造後
const result = !conditionA
  ? "Not A"
  : conditionB
  ? "A & B"
  : "A";

我承認，一開始，使用巢狀三元運算子的想法的確令人倒胃口。它看起來是一種編寫條件的巧妙方式。

然後我開始編寫業務邏輯，發現自己使用了巢狀的if else語句和一些非常可疑的條件邏輯。

我認為使用if和else更容易閱讀，因為它們是實際的單詞，有語義化，但當它們巢狀後，我開始很難理解發生了什麼，並在心裡默默跟蹤所有情況。

我認為這種模式取決於你、你的團隊的偏好。我在程式碼庫中也很好的使用這種方式。當然使用三元運算子具有兩面性，但就我個人而言，巢狀三元運算子真的越來越吸引我了。