clean-code-javascript - 🛁 JavaScript に適応したクリーンなコードの概念

(:bathtub: Clean Code concepts adapted for JavaScript)

Created at: 2016-11-26 06:25:41

Language: JavaScript

URL: https://github.com/ryanmcdermott/clean-code-javascript

License: MIT

クリーンコードJavaScript

序章

Robert C. Martin の著書Clean Codeのソフトウェアエンジニアリングの原則を JavaScript に適応させたもの。これはスタイルガイドではありません。これは、読みやすく、再利用可能で、リファクタリング可能なソフトウェアを JavaScriptで作成するためのガイドです。

ここに記載されているすべての原則に厳密に従う必要があるわけではありません。これらはガイドラインであり、それ以上のものではありませんが、 Clean Codeの作成者による長年の集合的な経験に基づいて成文化されたものです。

私たちのソフトウェアエンジニアリング技術は 50 歳を少し超えたばかりですが、まだ多くのことを学んでいます。ソフトウェアアーキテクチャがアーキテクチャ自体と同じくらい古いものになると、従うべきルールが難しくなる可能性があります。今のところ、これらのガイドラインを、あなたとあなたのチームが作成する JavaScript コードの品質を評価するための試金石として役立ててください。

もう 1 つ: これらを知っていても、すぐに優れたソフトウェア開発者になるわけではありません。また、それらを何年も使用しても、間違いを犯さないというわけではありません。湿った粘土が最終的な形に形作られるように、コードのすべての部分は最初のドラフトとして始まります。最後に、同僚と一緒にレビューするときに、欠陥を削ぎ落とします。改善が必要な最初のドラフトで自分を責めないでください。代わりにコードを打ち負かしてください！

変数

意味があり発音しやすい変数名を使用する

悪い：

const yyyymmdstr = moment().format("YYYY/MM/DD");

良い：

const currentDate = moment().format("YYYY/MM/DD");

⬆トップに戻る

同じ型の変数には同じ語彙を使用する

悪い：

getUserInfo();
getClientData();
getCustomerRecord();

良い：

getUser();

⬆トップに戻る

検索可能な名前を使用する

私たちはこれまでに書いたよりも多くのコードを読むでしょう。私たちが書くコードが読みやすく、検索可能であることが重要です。プログラムを理解する上で意味のある変数に名前を付けないことで、読者を傷つけます。名前を検索可能にします。buddy.jsや ESLintなどのツールは、名前のない定数を識別するのに役立ちます。

悪い：

// What the heck is 86400000 for?
setTimeout(blastOff, 86400000);

良い：

// Declare them as capitalized named constants.
const MILLISECONDS_PER_DAY = 60 * 60 * 24 * 1000; //86400000;

setTimeout(blastOff, MILLISECONDS_PER_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();
  // ...
  // ...
  // ...
  // Wait, what is `l` for again?
  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, color) {
  car.carColor = color;
}

良い：

const Car = {
  make: "Honda",
  model: "Accord",
  color: "Blue"
};

function paintCar(car, color) {
  car.color = color;
}

⬆トップに戻る

短絡や条件の代わりにデフォルトのパラメーターを使用する

多くの場合、デフォルトのパラメーターは短絡よりもクリーンです。

undefined

それらを使用する場合、関数は引数のデフォルト値のみを提供することに注意してください。

''

、

""

、

false

、

null

、

、などのその他の「偽の」値は

NaN

、デフォルト値に置き換えられません。

悪い：

function createMicrobrewery(name) {
  const breweryName = name || "Hipster Brew Co.";
  // ...
}

良い：

function createMicrobrewery(name = "Hipster Brew Co.") {
  // ...
}

⬆トップに戻る

機能

関数の引数 (理想的には 2 つ以下)

関数パラメーターの量を制限することは、関数のテストが容易になるため、非常に重要です。3 つを超えると、組み合わせの爆発が発生し、個別の引数ごとに多数の異なるケースをテストする必要があります。

1 つまたは 2 つの引数が理想的なケースであり、可能であれば 3 つを避ける必要があります。それ以上のものは統合する必要があります。通常、2 つ以上の引数がある場合、関数は多くのことをしようとしています。そうでない場合は、ほとんどの場合、より高いレベルのオブジェクトで引数として十分です。

JavaScript を使用すると、多くのクラス定型句を使用せずにオンザフライでオブジェクトを作成できるため、多くの引数が必要な場合はオブジェクトを使用できます。

関数が期待するプロパティを明確にするために、ES2015/ES6 分解構文を使用できます。これにはいくつかの利点があります。

関数シグネチャを見ると、どのプロパティが使用されているかがすぐにわかります。
名前付きパラメーターをシミュレートするために使用できます。
破壊は、関数に渡された引数オブジェクトの指定されたプリミティブ値も複製します。これにより、副作用を防ぐことができます。注: 引数オブジェクトから分解されたオブジェクトと配列は複製されません。
リンターは、未使用のプロパティについて警告することができますが、これは破壊せずには不可能です。

悪い：

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
});

⬆トップに戻る

関数は 1 つのことを行う必要があります

これは、ソフトウェアエンジニアリングにおいて最も重要なルールです。関数が複数のことを行う場合、作成、テスト、推論が難しくなります。関数を 1 つのアクションだけに分離できれば、簡単にリファクタリングでき、コードはずっときれいに読めます。このガイドからこれ以外に何も得られなければ、多くの開発者よりも先に進むことができます。

悪い：

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();

// It's hard to tell from the function name what is added
addToDate(date, 1);

良い：

function addMonthToDate(month, date) {
  // ...
}

const date = new Date();
addMonthToDate(1, date);

⬆トップに戻る

関数は 1 レベルの抽象化のみにする必要があります

抽象化のレベルが複数ある場合、通常、関数は過剰な処理を行います。関数を分割すると、再利用性が向上し、テストが容易になります。

悪い：

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;
}

⬆トップに戻る

重複コードを削除

コードの重複を避けるために最善を尽くしてください。ロジックを変更する必要がある場合に、何かを変更する場所が複数あることを意味するため、コードの重複は良くありません。

レストランを経営していて、すべてのトマト、タマネギ、ニンニク、スパイスなどの在庫を追跡している場合を想像してみてください。これを保持するリストが複数ある場合、トマトを使った料理を提供するときにすべてを更新する必要があります。それらの中で。リストが 1 つしかない場合、更新する場所は 1 つだけです。

多くの場合、2 つ以上のわずかに異なるものがあり、多くの共通点がありますが、それらの違いにより、ほとんど同じことを行う 2 つ以上の別個の関数が必要になるため、コードが重複することがあります。重複するコードを削除するということは、この一連のさまざまなものを 1 つの関数/モジュール/クラスだけで処理できる抽象化を作成することを意味します。

抽象化を正しく行うことは非常に重要です。そのため、クラスセクションで説明されている SOLID の原則に従う必要があります。悪い抽象化は重複コードよりも悪い可能性があるので、注意してください! そうは言っても、良い抽象化ができるなら、それをやってください！同じことを繰り返さないでください。そうしないと、1 つのことを変更したいときにいつでも複数の場所を更新していることに気付くでしょう。

悪い：

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) {
  let finalConfig = Object.assign(
    {
      title: "Foo",
      body: "Bar",
      buttonText: "Baz",
      cancellable: true
    },
    config
  );
  return finalConfig
  // config now equals: {title: "Order", body: "Bar", buttonText: "Send", cancellable: true}
  // ...
}

createMenu(menuConfig);

⬆トップに戻る

フラグを関数パラメーターとして使用しないでください

フラグは、この関数が複数のことを行うことをユーザーに伝えます。関数は 1 つのことを行う必要があります。ブール値に基づいて異なるコードパスに従っている場合は、関数を分割します。

悪い：

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}`);
}

⬆トップに戻る

副作用を避ける (パート 1)

関数は、値を取得して別の値を返す以外のことを行うと、副作用を引き起こします。副作用は、ファイルへの書き込み、グローバル変数の変更、または誤ってすべてのお金を見知らぬ人に配線する可能性があります.

さて、場合によってはプログラムに副作用を持たせる必要があります。前の例と同様に、ファイルへの書き込みが必要になる場合があります。あなたがしたいことは、これを行っている場所を一元化することです。特定のファイルに書き込む関数やクラスをいくつか持たないでください。それを行う1つのサービスを用意してください。唯一無二。

主なポイントは、オブジェクト間で構造を持たずに状態を共有する、何からでも書き込み可能な可変データ型を使用する、副作用が発生する場所を一元化しないなどのよくある落とし穴を避けることです。これができれば、他の大多数のプログラマーよりも幸せになれるでしょう。

悪い：

// Global variable referenced by following function.
// If we had another function that used this name, now it'd be an array and it could break it.
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'];

⬆トップに戻る

副作用を避ける (パート 2)

JavaScript では、一部の値は変更不可 (不変) であり、一部は変更可能 (ミュータブル) です。オブジェクトと配列は 2 種類の可変値であるため、関数にパラメーターとして渡すときは慎重に扱うことが重要です。JavaScript 関数は、オブジェクトのプロパティを変更したり、他の場所で簡単にバグを引き起こす可能性のある配列の内容を変更したりできます。

ショッピングカートを表す配列パラメーターを受け取る関数があるとします。関数がそのショッピングカート配列に変更を加えた場合 (購入するアイテムを追加するなど)、同じ

cart

配列を使用する他のすべての関数がこの追加の影響を受けます。それは素晴らしいことかもしれませんが、悪いこともあります。悪い状況を想像してみましょう:

ユーザーが「購入」ボタンをクリックすると

purchase

、ネットワーク要求を生成して

cart

アレイをサーバーに送信する関数が呼び出されます。ネットワーク接続が悪いため、

purchase

関数はリクエストを再試行し続ける必要があります。では、ネットワークリクエストが開始される前に、ユーザーが実際には欲しくないアイテムの [カートに追加] ボタンを誤ってクリックしてしまったらどうなるでしょうか。

cart

それが発生し、ネットワークリクエストが開始された場合、その購入関数は、配列が変更されたため、誤って追加されたアイテムを送信します。

優れた解決策は、

addItemToCart

関数が常にを複製し

cart

、編集して、複製を返すことです。これにより、古いショッピングカートをまだ使用している関数が変更の影響を受けないことが保証されます。

このアプローチについて言及する 2 つの注意事項:

入力オブジェクトを実際に変更したい場合もあるかもしれませんが、このプログラミング手法を採用すると、そのようなケースは非常にまれであることがわかります。ほとんどのものは、副作用がないようにリファクタリングできます!
大きなオブジェクトのクローンを作成すると、パフォーマンスの点で非常にコストがかかる可能性があります。幸いなことに、これは実際には大きな問題ではありません。なぜなら、この種のプログラミングアプローチを高速にし、オブジェクトや配列を手動で複製する場合ほどメモリを消費しない優れたライブラリがあるからです。

悪い：

const addItemToCart = (cart, item) => {
  cart.push({ item, date: Date.now() });
};

良い：

const addItemToCart = (cart, item) => {
  return [...cart, { item, date: Date.now() }];
};

⬆トップに戻る

グローバル関数に書き込まないでください

グローバルを汚染することは、JavaScript では悪い習慣です。別のライブラリと競合する可能性があり、API のユーザーは、本番環境で例外が発生するまでは賢明ではありません。例を考えてみましょう。JavaScript のネイティブ Array メソッドを拡張して、

diff

2 つの配列の違いを表示できるメソッドを作成したい場合はどうでしょうか? 新しい関数をに書き込むことはできます

Array.prototype

が、同じことをしようとした別のライブラリと衝突する可能性があります。その他のライブラリが

diff

、配列の最初と最後の要素の違いを見つけるために使用されていたとしたらどうでしょうか? これが、ES2015/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

これを最初に聞いたとき、ほとんどの人は「声明なしでどうやって何かをすることになっているのですか?」と言います。答えは、多くの場合、ポリモーフィズムを使用して同じタスクを達成できるということです。2 番目の質問は通常、「それは素晴らしいことですが、なぜそれを行う必要があるのでしょうか?」というものです。その答えは、以前に学んだクリーンなコードの概念です。関数は 1 つのことだけを行うべきです。ステートメントを持つクラスと関数がある場合

if

、関数が複数のことを行うことをユーザーに伝えています。1 つのことだけを行うことを忘れないでください。

悪い：

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();
  }
}

⬆トップに戻る

型チェックを避ける (パート 1)

JavaScript は型指定されていません。つまり、関数は任意の型の引数を取ることができます。時々、この自由に噛まれて、関数で型チェックをしたくなることがあります。これを回避する方法はたくさんあります。最初に考慮すべきことは、一貫した 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"));
}

⬆トップに戻る

型チェックを避ける (パート 2)

文字列や整数などの基本的なプリミティブ値を扱っていて、ポリモーフィズムを使用できないが、それでも型チェックの必要性を感じている場合は、TypeScript の使用を検討する必要があります。これは、標準の JavaScript 構文に加えて静的型付けを提供するため、通常の JavaScript の優れた代替手段です。通常の JavaScript を手動で型チェックする際の問題は、それをうまく行うには余分な言い回しが必要になるため、得られる偽の「型安全性」が失われた可読性を補えないことです。JavaScript をきれいに保ち、適切なテストを作成し、適切なコードレビューを行ってください。それ以外の場合は、すべてを TypeScript を使用して行います (これは、私が言ったように、優れた代替手段です!)。

悪い：

function combine(val1, val2) {
  if (
    (typeof val1 === "number" && typeof val2 === "number") ||
    (typeof val1 === "string" && typeof val2 === "string")
  ) {
    return val1 + val2;
  }

  throw new Error("Must be of type String or Number");
}

良い：

function combine(val1, val2) {
  return val1 + val2;
}

⬆トップに戻る

最適化しすぎない

最新のブラウザーは、実行時に内部で多くの最適化を行います。多くの場合、最適化を行っている場合は、時間を無駄にしているだけです。最適化が欠けている場所を確認するための優れたリソースがあります。可能な場合は修正されるまでの間、それらをターゲットにします。

悪い：

// On old browsers, each iteration with uncached `list.length` would be costly
// because of `list.length` recomputation. In modern browsers, this is optimized.
for (let i = 0, len = list.length; i < len; i++) {
  // ...
}

良い：

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

⬆トップに戻る

デッドコードを削除

デッドコードは、重複コードと同じくらい悪いものです。コードベースに保持する理由はありません。呼び出されていない場合は、削除してください。それでも必要な場合は、バージョン履歴で安全に保管されます。

悪い：

function oldRequestModule(url) {
  // ...
}

function newRequestModule(url) {
  // ...
}

const req = newRequestModule;
inventoryTracker("apples", req, "www.inventory-awesome.io");

良い：

function newRequestModule(url) {
  // ...
}

const req = newRequestModule;
inventoryTracker("apples", req, "www.inventory-awesome.io");

⬆トップに戻る

オブジェクトとデータ構造

ゲッターとセッターを使用する

単にオブジェクトのプロパティを探すよりも、getter と setter を使用してオブジェクトのデータにアクセスするほうがよい場合があります。"どうして？" あなたは尋ねるかもしれません。さて、ここに理由の整理されていないリストがあります：

When you want to do more beyond getting an object property, you don't have to look up and change every accessor in your codebase.
Makes adding validation simple when doing a
```
set
```
.
Encapsulates the internal representation.
Easy to add logging and error handling when getting and setting.
You can lazy load your object's properties, let's say getting it from a server.

Bad:

function makeBankAccount() {
  // ...

  return {
    balance: 0
    // ...
  };
}

const account = makeBankAccount();
account.balance = 100;

Good:

function makeBankAccount() {
  // this one is private
  let balance = 0;

  // a "getter", made public via the returned object below
  function getBalance() {
    return balance;
  }

  // a "setter", made public via the returned object below
  function setBalance(amount) {
    // ... validate before updating the balance
    balance = amount;
  }

  return {
    // ...
    getBalance,
    setBalance
  };
}

const account = makeBankAccount();
account.setBalance(100);

clean-code-javascript - 🛁 JavaScript に適応したクリーンなコードの概念

(:bathtub: Clean Code concepts adapted for JavaScript)

クリーンコードJavaScript

目次

序章

変数

意味があり発音しやすい変数名を使用する

同じ型の変数には同じ語彙を使用する

検索可能な名前を使用する

説明変数を使用する

メンタルマッピングを避ける

不要なコンテキストを追加しないでください

短絡や条件の代わりにデフォルトのパラメーターを使用する

機能

関数の引数 (理想的には 2 つ以下)

関数は 1 つのことを行う必要があります

関数名は何をするかを示すべきです

関数は 1 レベルの抽象化のみにする必要があります

重複コードを削除

Object.assign を使用してデフォルト オブジェクトを設定する

フラグを関数パラメーターとして使用しないでください

副作用を避ける (パート 1)

副作用を避ける (パート 2)

グローバル関数に書き込まないでください

命令型プログラミングよりも関数型プログラミングを好む

条件をカプセル化する

否定的な条件を避ける

条件を避ける

型チェックを避ける (パート 1)

型チェックを避ける (パート 2)

最適化しすぎない

デッドコードを削除

オブジェクトとデータ構造

ゲッターとセッターを使用する

Make objects have private members

Classes

Prefer ES2015/ES6 classes over ES5 plain functions

Use method chaining

Prefer composition over inheritance

SOLID

Single Responsibility Principle (SRP)

Open/Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)

Testing

Single concept per test

Concurrency

Use Promises, not callbacks

Async/Await are even cleaner than Promises

Error Handling

Don't ignore caught errors

Don't ignore rejected promises

Formatting

Use consistent capitalization

Function callers and callees should be close

Comments

Only comment things that have business logic complexity.

Don't leave commented out code in your codebase

Don't have journal comments

Avoid positional markers

Translation

About

Author：ryanmcdermott

Object.assign を使用してデフォルトオブジェクトを設定する