如何寫出優雅的 JS 程式碼，變數和函式的正確寫法

阿新 • • 發佈：2020-12-07

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

變數

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

// 不好的寫法
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.") {
  // ...
}

廣州品牌設計公司https://www.houdianzi.com PPT模板下載大全https://redbox.wode007.com

函式

函式引數（理想情況下為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) {
  config.title = config.title || "Foo";
  config.body = config.body || "Bar";
  config.buttonText = config.buttonText || "Baz";
  config.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() {
  name = 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陣列，編輯它，然後返回克隆。這可以確保購物車引用的其他函式不會受到任何更改的影響。

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

1.可能在某些情況下，我們確實需要修改輸入物件，但是當我們採用這種程式設計實踐時，會發現這種情況非常少見，大多數東西都可以被改造成沒有副作用。

2.就效能而言，克隆大物件可能會非常昂貴。幸運的是，在實踐中這並不是一個大問題，因為有很多很棒的庫使這種程式設計方法能夠快速進行，並且不像手動克隆物件和陣列那樣佔用大量記憶體。

// 不好的寫法
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++) {
  // ...
}

如何寫出優雅的 JS 程式碼，變數和函式的正確寫法

變數

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

對同一型別的變數使用相同的詞彙

使用可搜尋的名字

使用解釋性變數

避免費腦的猜測

無需新增不必要的上下文

使用預設引數代替邏輯或(與)運算

函式

函式引數（理想情況下為2個或更少）

函式應該只做一件事

函式名稱應說明其作用

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

刪除重複的程式碼

使用Object.assign設定預設物件

不要使用標誌作為函式引數

避免副作用(第一部分)

避免副作用(第二部分)

不要寫全域性函式

儘量使用函數語言程式設計而非命令式

封裝條件

避免使用非條件

避免使用過多條件

避免型別檢查

不要過度優化

相關推薦