我喜歡的5個編程技巧

在這篇文章中，我介紹了一些編程時嘗試使用的模式。這些模式是多年來我本身在工做中實踐的結果，也有是從同事那裏偷偷學到的。

這些模式沒有特定的順序，只是一個簡單的集合。

提早退出（early exits）

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

  // check for specific case
  if (rawData.length == 0) {
    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

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更容易閱讀，由於它們是實際的單詞，有語義化，但當它們嵌套後，我開始很難理解發生了什麼，並在內心默默跟蹤全部狀況。

我認爲這種模式取決於你、你的團隊的偏好。我在代碼庫中也很好的使用這種方式。固然使用三元運算符具備兩面性，但就我我的而言，嵌套三元運算符真的愈來愈吸引我了。

更多信息：Nested Ternaries are Great by Eric Elliot

若是對你有幫助，請關注【前端技能解鎖】：