元文書:https://github.com/airbnb/javascript

Airbnb JavaScript スタイルガイド() {

常に気をつけたい、JavaScriptへの正しい接し方

他のスタイルガイドたち

目次

  1. 型(Types)
  2. 参照(References)
  3. オブジェクト(Objects)
  4. 配列(Arrays)
  5. 構造化代入(Destructuring)
  6. 文字列(Strings)
  7. 関数(Functions)
  8. アロー関数(Arrow Functions)
  9. コンストラクタ(Constructors)
  10. モジュール(Modules)
  11. イテレータとジェネレータ(Iterators and Generators)
  12. プロパティ(Properties)
  13. 変数(Variables)
  14. 巻き上げ(Hoisting)
  15. 条件式と等価式(Comparison Operators & Equality)
  16. ブロック(Blocks)
  17. コメント(Comments)
  18. 空白(Whitespace)
  19. カンマ(Commas)
  20. セミコロン(Semicolons)
  21. 型変換と強制(Type Casting & Coercion)
  22. 命名規則(Naming Conventions)
  23. アクセッサ(Accessors)
  24. イベント(Events)
  25. jQuery(jQuery)
  26. ECMAScript 5 互換性(ECMAScript 5 Compatibility)
  27. ECMAScript 6 スタイル(ECMAScript 6 Styles)
  28. テスト(Testing)
  29. パフォーマンス(Performance)
  30. 参考文献(Resources)
  31. 共鳴者(In the Wild)
  32. 翻訳(Translation)
  33. JavaScriptスタイルガイドへの手引き(The JavaScript Style Guide Guide)
  34. Javascriptスタイルガイドについてのchat(Chat With Us About JavaScript)
  35. 貢献者(Contributors)
  36. ライセンス(License)

型(Types)

⬆ ページのTopへ戻る

参照(References)

Why? This ensures that you can’t reassign your references, which can lead to bugs and difficult to comprehend code.

なぜ? 参照を再割り当でできないことで、バグに繋がりやすく理解しがたいコードになることを防ぎます。

```javascript
// bad
var a = 1;
var b = 2;

// good
const a = 1;
const b = 2;
```

Why? let is block-scoped rather than function-scoped like var.

なぜ? 関数スコープの var よりむしろ、ブロックスコープの let

```javascript
// bad
var count = 1;
if (true) {
  count += 1;
}

// good, use the let.
let count = 1;
if (true) {
  count += 1;
}
```

⬆ ページのTopへ戻る

オブジェクト(Objects)

Why? They allow you to define all the properties of an object in one place.

なぜ? こうすることで、オブジェクトのプロパティを1箇所で定義することができます。

```javascript
function getKey(k) {
  return a `key named ${k}`;
}

// bad
const obj = {
  id: 5,
  name: 'San Francisco',
};
obj[getKey('enabled')] = true;

// good
const obj = {
  id: 5,
  name: 'San Francisco',
  [getKey('enabled')]: true
};
```

Why? It is shorter to write and descriptive.

Why? 記述や説明が簡潔になるからです。

```javascript
const lukeSkywalker = 'Luke Skywalker';

// bad
const obj = {
  lukeSkywalker: lukeSkywalker,
};

// good
const obj = {
  lukeSkywalker,
};
```

Why? It’s easier to tell which properties are using the shorthand.

なぜ? どのプロパティが短縮構文を利用しているか分かりやすいからです。

```javascript
const anakinSkywalker = 'Anakin Skywalker';
const lukeSkywalker = 'Luke Skywalker';

// bad
const obj = {
  episodeOne: 1,
  twoJediWalkIntoACantina: 2,
  lukeSkywalker,
  episodeThree: 3,
  mayTheFourth: 4,
  anakinSkywalker,
};

// good
const obj = {
  lukeSkywalker,
  anakinSkywalker,
  episodeOne: 1,
  twoJediWalkIntoACantina: 2,
  episodeThree: 3,
  mayTheFourth: 4,
};
```

⬆ ページのTopへ戻る

配列(Arrays)

⬆ ページのTopへ戻る

構造化代入(Destructuring)

Why? Destructuring saves you from creating temporary references for those properties.

なぜ? 構造化代入を利用することで、それらのプロパティのための中間的な参照を減らすことができます。

```javascript
// bad
function getFullName(user) {
  const firstName = user.firstName;
  const lastName = user.lastName;

  return `${firstName} ${lastName}`;
}

// good
function getFullName(obj) {
  const { firstName, lastName } = obj;
  return `${firstName} ${lastName}`;
}

// best
function getFullName({ firstName, lastName }) {
  return `${firstName} ${lastName}`;
}
```

Why? You can add new properties over time or change the order of things without breaking call sites.

なぜ? こうすることで、後で新しいプロパティを追加したり、呼び出し元に影響することなく順序を変更することができます。

```javascript
// bad
function processInput(input) {
  // then a miracle occurs
  // その後、奇跡が起こります。
  return [left, right, top, bottom];
}

// the caller needs to think about the order of return data
// 呼び出し者で返却されるデータの順番を考慮する必要があります。
const [left, __, top] = processInput(input);

// good
function processInput(input) {
  // then a miracle occurs
  // その後、奇跡が起こります。
  return { left, right, top, bottom };
}

// the caller selects only the data they need
// 呼び出し元は必要なデータのみ選択すればいい。
const { left, right } = processInput(input);
```

⬆ ページのTopへ戻る

文字列(Strings)

Why? Template strings give you a readable, concise syntax with proper newlines and string interpolation features.

なぜ? Template strings は文字列補完機能・複数行文字列機能を持つ簡潔な構文で、可読性が良いからです。

```javascript
// bad
function sayHi(name) {
  return 'How are you, ' + name + '?';
}

// bad
function sayHi(name) {
  return ['How are you, ', name, '?'].join();
}

// good
function sayHi(name) {
  return `How are you, ${name}?`;
}
```   - [6.5](#6.5) <a name='6.5'></a> Never use `eval()` on a string, it opens too many vulnerabilities.   - [6.5](#6.5) <a name='6.5'></a> 絶対に `eval()` を利用しないでください。これは、いままで数多くの脆弱性を作って来たからです。

⬆ ページのTopへ戻る

関数(Functions)

Why? Function declarations are named, so they’re easier to identify in call stacks. Also, the whole body of a function declaration is hoisted, whereas only the reference of a function expression is hoisted. This rule makes it possible to always use Arrow Functions in place of function expressions.

なぜ? 名前が付けられた関数宣言はコールスタックで簡単に見分けることができます。さらに関数宣言は関数の本体が巻き上げられます。それに対し、関数式は参照だけが巻き上げられます。 このルールにより、関数式の部分を常にアロー関数で置き換えて利用することができます。

```javascript
// bad
const foo = function () {
};

// good
function foo() {
}
```

Why? ... is explicit about which arguments you want pulled. Plus rest arguments are a real Array and not Array-like like arguments.

なぜ? ... を利用することで、いつくかのパラメータを利用したいことを明らかにすることができます。加えてrestパラメータは arguments の様なArray-likeなオブジェクトではなく正真正銘のArrayです。

```javascript
// bad
function concatenateAll() {
  const args = Array.prototype.slice.call(arguments);
  return args.join('');
}

// good
function concatenateAll(...args) {
  return args.join('');
}
```

Why? They are confusing to reason about.

なぜ? 混乱させるからです。

  var b = 1;
  // bad
  function count(a = b++) {
    console.log(a);
  }
  count();  // 1
  count();  // 2
  count(3); // 3
  count();  // 3

⬆ ページのTopへ戻る

アロー関数(Arrow Functions)

Why? It creates a version of the function that executes in the context of this, which is usually what you want, and is a more concise syntax.

なぜ? アロー関数はそのコンテキストの this で実行するバージョンの関数を作成します。これは通常期待通りの動作をし、より簡潔な構文だからです。

Why not? If you have a fairly complicated function, you might move that logic out into its own function declaration.

利用するべきではない? 複雑な関数でロジックを定義した関数の外側に移動したいケース。

```javascript
// bad
[1, 2, 3].map(function (x) {
  const y = x + 1;
  return x * y;
});

// good
[1, 2, 3].map((x) => {
  const y = x + 1;
  return x * y;
});
```

Why? Syntactic sugar. It reads well when multiple functions are chained together.

なぜ? 糖衣構文(読みやすさのために導入される構文)だからです。複数の関数が連結される場合に読みやすくなります。

Why not? If you plan on returning an object.

使うべきではない? オブジェクトを返すケース。

```javascript
// good
[1, 2, 3].map(number => `A string containing the ${number}.`);

// bad
[1, 2, 3].map(number => {
  const nextNumber = number + 1;
  `A string containing the ${nextNumber}.`;
});

// good
[1, 2, 3].map(number => {
  const nextNumber = number + 1;
  return `A string containing the ${nextNumber}.`;
});
```

Why? It shows clearly where the function starts and ends.

なぜ? 関数の開始と終了部分が分かりやすく見えるためです。

```js
// bad
[1, 2, 3].map(number => 'As time went by, the string containing the ' +
  `${number} became much longer. So we needed to break it over multiple ` +
  'lines.'
);

// good
[1, 2, 3].map(number => (
  `As time went by, the string containing the ${number} became much ` +
  'longer. So we needed to break it over multiple lines.'
));
```

Why? Less visual clutter.

なぜ? あまり見難くないからです。

```javascript
// good
[1, 2, 3].map(x => x * x);

// good
[1, 2, 3].reduce((y, x) => x + y);
```

⬆ ページのTopへ戻る

コンストラクタ(Constructors)

Why? class syntax is more concise and easier to reason about.

なぜ? class 構文は簡潔で意図がわかりやすいからです。

```javascript
// bad
function Queue(contents = []) {
  this._queue = [...contents];
}
Queue.prototype.pop = function() {
  const value = this._queue[0];
  this._queue.splice(0, 1);
  return value;
}

// good
class Queue {
  constructor(contents = []) {
    this._queue = [...contents];
  }
  pop() {
    const value = this._queue[0];
    this._queue.splice(0, 1);
    return value;
  }
}
```

Why? It is a built-in way to inherit prototype functionality without breaking instanceof.

なぜ? プロトタイプ継承するためにビルトインされた方法で、instanceof を破壊することがないためです。

```javascript
// bad
const inherits = require('inherits');
function PeekableQueue(contents) {
  Queue.apply(this, contents);
}
inherits(PeekableQueue, Queue);
PeekableQueue.prototype.peek = function() {
  return this._queue[0];
}

// good
class PeekableQueue extends Queue {
  peek() {
    return this._queue[0];
  }
}
```

⬆ ページのTopへ戻る

モジュール(Modules)

Why? Modules are the future, let’s start using the future now.

Why? モジュールは将来性があります。未来を先取りして使いましょう。

```javascript
// bad
const AirbnbStyleGuide = require('./AirbnbStyleGuide');
module.exports = AirbnbStyleGuide.es6;

// ok
import AirbnbStyleGuide from './AirbnbStyleGuide';
export default AirbnbStyleGuide.es6;

// best
import { es6 } from './AirbnbStyleGuide';
export default es6;
```

Why? This makes sure you have a single default export.

なぜ? single default exportであることに注意する必要があるからです。

```javascript
// bad
import * as AirbnbStyleGuide from './AirbnbStyleGuide';

// good
import AirbnbStyleGuide from './AirbnbStyleGuide';
```

Why? Although the one-liner is concise, having one clear way to import and one clear way to export makes things consistent.

なぜ? ワンライナーは簡潔ではありますが、importとexportの方法を明確に1つとすることで一貫性を保つことができます。

```javascript
// bad
// filename es6.js
export { es6 as default } from './airbnbStyleGuide';

// good
// filename es6.js
import { es6 } from './AirbnbStyleGuide';
export default es6;
```

⬆ ページのTopへ戻る

イテレータとジェネレータ(Iterators and Generators)

Why? This enforces our immutable rule. Dealing with pure functions that return values is easier to reason about than side-effects.

なぜ? これはimmutable(不変)ルールを適用します。値を返ような関数の中身の処理を気にするより副作用について推測するほうが簡単です。

```javascript
const numbers = [1, 2, 3, 4, 5];

// bad
let sum = 0;
for (let num of numbers) {
  sum += num;
}

sum === 15;

// good
let sum = 0;
numbers.forEach((num) => sum += num);
sum === 15;

// best (use the functional force)
const sum = numbers.reduce((total, num) => total + num, 0);
sum === 15;
```

Why? They don’t transpile well to ES5.

なぜ? ES5にうまくトランスパイルできないから。

⬆ ページのTopへ戻る

プロパティ(Properties)

⬆ ページのTopへ戻る

変数(Variables)

Why? This is helpful when later on you might need to assign a variable depending on one of the previous assigned variables.

なぜ? 以前に割り当てた変数に応じて、後で新しい変数を追加する場合に有用だからです。

```javascript
// bad
let i, len, dragonball,
    items = getItems(),
    goSportsTeam = true;

// bad
let i;
const items = getItems();
let dragonball;
const goSportsTeam = true;
let len;

// good
const goSportsTeam = true;
const items = getItems();
let dragonball;
let i;
let length;
```

Why? let and const are block scoped and not function scoped.

なぜ? letconst はブロックスコープだからです。関数スコープではありません。

```javascript
// good
function() {
  test();
  console.log('doing stuff..');

  //..other stuff..

  const name = getName();

  if (name === 'test') {
    return false;
  }

  return name;
}

// bad - unnecessary function call
function(hasName) {
  const name = getName();

  if (!hasName) {
    return false;
  }

  this.setFirstName(name);

  return true;
}

// good
function(hasName) {
  if (!hasName) {
    return false;
  }

  const name = getName();
  this.setFirstName(name);

  return true;
}
```

⬆ ページのTopへ戻る

巻き上げ(Hoisting)

⬆ ページのTopへ戻る

条件式と等価式(Comparison Operators & Equality)

⬆ ページのTopへ戻る

ブロック(Blocks)

⬆ ページのTopへ戻る

コメント(Comments)

⬆ ページのTopへ戻る

空白(Whitespace)

⬆ ページのTopへ戻る

カンマ(Commas)

Why? This leads to cleaner git diffs. Also, transpilers like Babel will remove the additional trailing comma in the transpiled code which means you don’t have to worry about the trailing comma problem in legacy browsers.

なぜ? これはクリーンなgitの差分につながります。また、Babelの様なトランスパイラはトランスパイルする際に末尾の余計なカンマを除去します。これは、レガシーブラウザでの余計なカンマ問題を心配する必要がないことを意味します。

```javascript
// bad - git diff without trailing comma
const hero = {
     firstName: 'Florence',
-    lastName: 'Nightingale'
+    lastName: 'Nightingale',
+    inventorOf: ['coxcomb graph', 'modern nursing']
};

// good - git diff with trailing comma
const hero = {
     firstName: 'Florence',
     lastName: 'Nightingale',
+    inventorOf: ['coxcomb chart', 'modern nursing'],
};

// bad
const hero = {
  firstName: 'Dana',
  lastName: 'Scully'
};

const heroes = [
  'Batman',
  'Superman'
];

// good
const hero = {
  firstName: 'Dana',
  lastName: 'Scully',
};

const heroes = [
  'Batman',
  'Superman',
];
```

⬆ ページのTopへ戻る

セミコロン(Semicolons)

⬆ ページのTopへ戻る

型変換と強制(Type Casting & Coercion)

⬆ ページのTopへ戻る

命名規則(Naming Conventions)

⬆ ページのTopへ戻る

アクセッサ(Accessors)

⬆ ページのTopへ戻る

イベント(Events)

⬆ ページのTopへ戻る

jQuery

⬆ ページのTopへ戻る

ECMAScript 5 互換性(ECMAScript 5 Compatibility)

⬆ ページのTopへ戻る

ECMAScript 6 Styles

  1. Arrow Functions
  2. Classes
  3. Object Shorthand
  4. Object Concise
  5. Object Computed Properties
  6. Template Strings
  7. Destructuring
  8. Default Parameters
  9. Rest
  10. Array Spreads
  11. Let and Const
  12. Iterators and Generators
  13. Modules

⬆ ページのTopへ戻る

テスト(Testing)

⬆ ページのTopへ戻る

パフォーマンス(Performance)

⬆ ページのTopへ戻る

参考文献(Resources)

Learning ES6

Read This

Tools

Other Style Guides

Other Styles

Further Reading

Books

Blogs

Podcasts

⬆ ページのTopへ戻る

共鳴者(In the Wild)

This is a list of organizations that are using this style guide. Send us a pull request and we’ll add you to the list.

これはこのスタイルガイドを使用している組織の一覧表です。このリストに追加して欲しい場合は、pull requestかissueを挙げてください。

⬆ ページのTopへ戻る

翻訳(Translation)

This style guide is also available in other languages:

このスタイルガイドは他の言語でも利用できます。

JavaScriptスタイルガイドへの手引き(The JavaScript Style Guide Guide)

Javascriptスタイルガイドについてのchat(Chat With Us About JavaScript)

貢献者(Contributors)

License

(The MIT License)

Copyright (c) 2014 Airbnb

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ‘Software’), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED ‘AS IS’, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

MITライセンス

著作権(c) 2014 Airbnb
翻訳 2015 mitsuruog

このソフトウェアおよび関連する文書ファイル(以下「本ソフトウェア」という。)の複製物を取得するあらゆる者に対し、 以下の条件にしたがって本ソフトウェアを制限なしに扱うことを無償で許諾する。 そこには、本ソフトウェアの複製を使用し、複製し、改変し、結合し、公表し、頒布し、サブライセンスし、 および/または販売する権利、また、本ソフトウェアを与えられた者に上記のようにすることを許諾する権利を含むがそれらに限られない。

上記の著作権表示および本許諾表示は「本ソフトウェア」のすべての複製物または重要部分の中に含めなければならない。

「本ソフトウェア」は「現状のまま」で提供され、明示または黙示を問わず、 商品性、特定目的への適合性および非侵害を含むがそれに限られない、あらゆる種類の保証も伴わないものとする。 著作者または著作権者は、契約、不法行為またはその他の行為であるかにかかわらず、 ソフトウェアまたはソフトウェアの使用もしくはその他の取り扱いから、またはそれらに関連して生じた、 いかなるクレーム、損害賠償その他の責任を負わない。

⬆ ページのTopへ戻る

補足(Amendments)

We encourage you to fork this guide and change the rules to fit your team’s style guide. Below, you may list some amendments to the style guide. This allows you to periodically update your style guide without having to deal with merge conflicts.

我々はこのガイドをforkして、あなたのチームに適したスタイルガイドとして変更することを勧めます。以下にあなたがスタイルガイドに加えた変更をリストにしてください。 こうすることで、マージの煩わしさに気を取られることなく、あなたのスタイルガイドを定期的に更新することができます。

};