開発

2017.09.27

JavaScriptスタイルガイド 15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか（翻訳）

hachi8833

シェア
ツイート
ブックマーク
LINE

1〜8: 型、参照、オブジェクト、配列、関数ほか
9〜14: クラス、モジュール、イテレータ、プロパティ、変数、巻き上げ
15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか -- 本記事

概要

AirbnbによるJavaScriptスタイルガイドです。
MITライセンスに基いて翻訳・公開いたします。

英語スタイルガイド: airbnb/javascript: README.md
更新日: 2017/09/08
著者: Airbnb

github.com/airbnbより

凡例

原文にはありませんが、項目ごとに目安となる分類を【】で示しました。

【必須】【禁止】：従わないと技術的な悪影響が生じる
【推奨】【非推奨】：技術上の理由から強く推奨される、または推奨されない
【選択】：採用してもしなくてもよいスタイル
【スタイル】：読みやすさのためのスタイル統一指示
【知識】：指示に該当しない基礎知識

JavaScriptスタイルガイド 15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか（翻訳）

15. 比較演算子と相等条件

15.1 【必須】`===`や`!==`を使うこと。
【禁止】`==`や`!=`は使わないこと。

eslint: eqeqeq

15.2 【知識】`if`文などの条件文では、`ToBoolean`抽象メソッドで強制的に式を評価する。評価のルールは常に以下に従うことに注意。

Objectsの評価はtrueになる
Undefinedの評価はfalseになる
Nullの評価はfalseになる
Booleansの評価はboolean値になる
Numbersの評価は、+0、-0、NaNの場合はfalse、それ以外はtrueになる
Stringsの評価は、空文字列''の場合はfalse、それ以外はtrueになる

if ([0] && []) {
  // true
  // 配列は（たとえ空でも）オブジェクトであり、オブジェクトの評価はtrueになる
}

15.3 【推奨】boolean値については演算子を使わない省略記法を使うこと。ただし文字列同士や数値同士の比較は明示的に演算子を使うこと。

// Bad
if (isValid === true) {
  // ...
}

// Good
if (isValid) {
  // ...
}

// Bad
if (name) {
  // ...
}

// Good
if (name !== '') {
  // ...
}

// Bad
if (collection.length) {
  // ...
}

// Good
if (collection.length > 0) {
  // ...
}

15.4 【知識】詳しくはTruth Equality and JavaScript（Angus Croll）を参照。

15.5 【推奨】`case`句や`default`句のレキシカル（静的）な宣言（`let`、`const`、`function`、`class`など）は波かっこ`{ }`で囲んでブロックを作成すること。

理由: レキシカルな宣言のスコープはswitchブロック全体になるが、代入時まで初期化されないため、そのcaseが実行されないと初期化されない。このため、複数のcaseで同じ定義を行おうとすると問題が生じることがある。

eslint rules: no-case-declarations.

// Bad
switch (foo) {
  case 1:
    let x = 1;
    break;
  case 2:
    const y = 2;
    break;
  case 3:
    function f() {
      // ...
    }
    break;
  default:
    class C {}
}

// Good
switch (foo) {
  case 1: {
    let x = 1;
    break;
  }
  case 2: {
    const y = 2;
    break;
  }
  case 3: {
    function f() {
      // ...
    }
    break;
  }
  case 4:
    bar();
    break;
  default: {
    class C {}
  }
}

15.6 【禁止】三項演算子はネストするべきではない。
【推奨】三項演算子は1行で書く式として用いる（複数行に分けない）のが一般的。

eslint rules: no-nested-ternary.

// Bad
const foo = maybe1 > maybe2
  ? "bar"
  : value1 > value2 ? "baz" : null;

// 少しまし
const maybeNull = value1 > value2 ? 'baz' : null;

const foo = maybe1 > maybe2
  ? 'bar'
  : maybeNull;

// ベスト
const maybeNull = value1 > value2 ? 'baz' : null;

const foo = maybe1 > maybe2 ? 'bar' : maybeNull;

15.7 【非推奨】三項演算子の乱用は避ける（不要な三項演算子を使わない）。

eslint rules: no-unneeded-ternary.

// Bad
const foo = a ? a : b;
const bar = c ? true : false;
const baz = c ? false : true;

// Good
const foo = a || b;
const bar = !!c;
const baz = !c;

16. ブロック（block）

16.1 【スタイル】ブロックは複数行形式の波かっこ`{ }`にすること（ブロックを1行で書かない）。

// Bad
if (test)
  return false;

// Good
if (test) return false;

// Good
if (test) {
  return false;
}

// Bad
function foo() { return false; }

// Good
function bar() {
  return false;
}

16.2 【スタイル】`if`と`else`を使う複数行ブロックでは、`else`と同じ行で`if`のブロックを閉じること。

eslint: brace-style
jscs: disallowNewlineBeforeBlockStatements

// Bad
if (test) {
  thing1();
  thing2();
}
else {
  thing3();
}

// Good
if (test) {
  thing1();
  thing2();
} else {
  thing3();
}

17. 制御文（control statement）

17.1 【選択】`if`や`while`などの制御文が1行の最大文字数を超える場合は、各条件を1行ずつに分けてよい。論理演算子を条件行の冒頭に置くか末尾に置くかはどちらに決めてもよい。

// Bad
if ((foo === 123 || bar === 'abc') && doesItLookGoodWhenItBecomesThatLong() && isThisReallyHappening()) {
  thing1();
}

// Bad
if (foo === 123 &&
  bar === 'abc') {
  thing1();
}

// Bad
if (foo === 123
  && bar === 'abc') {
  thing1();
}

// Good
if (
  (foo === 123 || bar === "abc") &&
  doesItLookGoodWhenItBecomesThatLong() &&
  isThisReallyHappening()
) {
  thing1();
}

// Good
if (foo === 123 && bar === 'abc') {
  thing1();
}

// Good
if (
  foo === 123 &&
  bar === 'abc'
) {
  thing1();
}

// Good
if (
  foo === 123
  && bar === 'abc'
) {
  thing1();
}

18. コメント（comment）

18.1 【スタイル】複数行コメントは`/** ... */`で書くこと

// Bad
// make()はtag名に渡されたものに応じて
// 新しい要素を返す
//
// @param {String} tag
// @return {Element} element
function make(tag) {

  // ...

  return element;
}

// Good
/**
 * make() returns a new element
 * based on the passed-in tag name
 */
function make(tag) {

  // ...

  return element;
}

18.2 【スタイル】1行コメントは`//`を使い、コメント対象行のすぐ上に書くこと。1行コメントの上は空行にすること（ブロックの1行目にコメントする場合を除く）。

// Bad
const active = true;  // 現在のtab

// Good
// 現在のtab
const active = true;

// Bad
function getType() {
  console.log('fetching type...');
  // デフォルト値を'no type'に設定
  const type = this.type || 'no type';

  return type;
}

// Good
function getType() {
  console.log('fetching type...');

  // デフォルト値を'no type'に設定
  const type = this.type || 'no type';

  return type;
}

// これもよい
function getType() {
  // デフォルト値を'no type'に設定
  const type = this.type || 'no type';

  return type;
}

18.3 【スタイル】可読性のため、コメント記号とコメント文冒頭の間にスペースを1つ置くこと。

eslint: spaced-comment

// Bad
//現在のtab
const active = true;

// Good
// 現在のtab
const active = true;

// Bad
/**
 *make()はtag名に渡されたものに応じて
 *新しい要素を返す
 */
function make(tag) {

  // ...

  return element;
}

// Good
/**
 * make()はtag名に渡されたものに応じて
 * 新しい要素を返す
 */
function make(tag) {

  // ...

  return element;
}

18.4 【推奨】コメント文冒頭に`FIXME`や`TODO`を置くと、問題点を他の開発者に見てもらうときや、実装の必要な問題の解決方法を指示するときに問題箇所を見つけやすくなる。このコメント方法は、`FIXME: --解明が必要`や`TODO: -- 要実装`のように具体的なアクションを指示するため、標準的なコメント方法とは異なる。

18.5 【推奨】問題点の指摘には`// FIXME:`を使うこと。

class Calculator extends Abacus {
  constructor() {
    super();

    // FIXME: ここでグローバル変数を使うべきではない
    total = 0;
  }
}

18.6 【推奨】問題の解決方法の指示には`// TODO:`を使うこと。

class Calculator extends Abacus {
  constructor() {
    super();

    // TODO: totalはオプションパラメータで構成すべき
    this.total = 0;
  }
}

19. スペース（whitespace）

19.1 【スタイル】ソフトタブはスペース2文字のものを使うこと。

eslint: indent
jscs: validateIndentation

// Bad
function foo() {
∙∙∙∙let name;
}

// Bad
function bar() {
∙let name;
}

// Good
function baz() {
∙∙let name;
}

19.2 【スタイル】開始波かっこ`{`の直前にはスペースを1つ置くこと。

eslint: space-before-blocks
jscs: requireSpaceBeforeBlockStatements

// Bad
function test(){
  console.log('test');
}

// Good
function test() {
  console.log('test');
}

// Bad
dog.set('attr',{
  age: '1 year',
  breed: 'Bernese Mountain Dog',
});

// Good
dog.set('attr', {
  age: '1 year',
  breed: 'Bernese Mountain Dog',
});

19.3 【スタイル】`if`や`while`などの制御文で使われる開始丸かっこ`(`の前にはスペースを1文字置くこと。引数リストで使われる開始丸かっこ`(`と、関数呼び出しや関数宣言の関数名との間にはスペースを置かないこと。

eslint: keyword-spacing
jscs: requireSpaceAfterKeywords

// Bad
if(isJedi) {
  fight ();
}

// Good
if (isJedi) {
  fight();
}

// Bad
function fight () {
  console.log ('Swooosh!');
}

// Good
function fight() {
  console.log('Swooosh!');
}

19.4 【スタイル】演算子の前後にはスペースを1つ置くこと。

eslint: space-infix-ops
jscs: requireSpaceBeforeBinaryOperators, requireSpaceAfterBinaryOperators

// Bad
const x=y+5;

// Good
const x = y + 5;

19.5 【スタイル】ファイルの末尾には改行文字を1つだけ置くこと。

eslint: eol-last

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

// Bad
import { es6 } from './AirbnbStyleGuide';
  // ...
export default es6;↵
↵

// Good
import { es6 } from './AirbnbStyleGuide';
  // ...
export default es6;↵

19.6 【スタイル】メソッドチェーンが3つ以上になる場合はインデントすること。その場合ドット`.`はメソッド名の（末尾ではなく）冒頭に付けて、その行が新しい文ではなくメソッド呼び出しであることを示す。

eslint: newline-per-chained-call, no-whitespace-before-property

// Bad
$('#items').find('.selected').highlight().end().find('.open').updateCount();

// Bad
$('#items').
  find('.selected').
    highlight().
    end().
  find('.open').
    updateCount();

// Good
$('#items')
  .find('.selected')
    .highlight()
    .end()
  .find('.open')
    .updateCount();

// Bad
const leds = stage.selectAll('.led').data(data).enter().append('svg:svg').classed('led', true)
    .attr('width', (radius + margin) * 2).append('svg:g')
    .attr('transform', `translate(${radius + margin},${radius + margin})`)
    .call(tron.led);

// Good
const leds = stage.selectAll('.led')
    .data(data)
  .enter().append('svg:svg')
    .classed('led', true)
    .attr('width', (radius + margin) * 2)
  .append('svg:g')
    .attr('transform', `translate(${radius + margin},${radius + margin})`)
    .call(tron.led);

// Good
const leds = stage.selectAll('.led').data(data);

19.7 【スタイル】ブロックと次の文の間は1行空けること。

jscs: requirePaddingNewLinesAfterBlocks

// Bad
if (foo) {
  return bar;
}
return baz;

// Good
if (foo) {
  return bar;
}

return baz;

// Bad
const obj = {
  foo() {
  },
  bar() {
  },
};
return obj;

// Good
const obj = {
  foo() {
  },

  bar() {
  },
};

return obj;

// Bad
const arr = [
  function foo() {
  },
  function bar() {
  },
];
return arr;

// Good
const arr = [
  function foo() {
  },

  function bar() {
  },
];

return arr;

19.8 【スタイル】波かっこ`{ }`ブロックのすぐ内側に空行を置かないこと。

eslint: padded-blocks
jscs: disallowPaddingNewlinesInBlocks

// Bad
function bar() {

  console.log(foo);

}

// これも不可
if (baz) {

  console.log(qux);
} else {
  console.log(foo);

}

// Good
function bar() {
  console.log(foo);
}

// Good
if (baz) {
  console.log(qux);
} else {
  console.log(foo);
}

19.9 【スタイル】丸かっこ`( )`の内側にスペースを置かないこと。

eslint: space-in-parens
jscs: disallowSpacesInsideParentheses

// Bad
function bar( foo ) {
  return foo;
}

// Good
function bar(foo) {
  return foo;
}

// Bad
if ( foo ) {
  console.log(foo);
}

// Good
if (foo) {
  console.log(foo);
}

19.10 【スタイル】角かっこ`[ ]`の内側にスペースを置かないこと。

eslint: array-bracket-spacing
jscs: disallowSpacesInsideArrayBrackets

// Bad
const foo = [ 1, 2, 3 ];
console.log(foo[ 0 ]);

// Good
const foo = [1, 2, 3];
console.log(foo[0]);

19.11 【スタイル】波かっこ`{ }` の内側にはスペースを置くこと。

eslint: object-curly-spacing
jscs: requireSpacesInsideObjectBrackets

// Bad
const foo = {clark: 'kent'};

// Good
const foo = { clark: 'kent' };

19.12 【スタイル】1行あたりの文字数が100文字（スペースを含む）を超えることは避ける。**注:* 上述のとおり、長い文字列はこのルールの適用範囲外であり、長い文字列を分割すべきではない。

eslint: max-len
jscs: maximumLineLength

理由: 読みやすさとメンテナンス性のため。

// Bad
const foo = jsonData && jsonData.foo && jsonData.foo.bar && jsonData.foo.bar.baz && jsonData.foo.bar.baz.quux && jsonData.foo.bar.baz.quux.xyzzy;

// Bad
$.ajax({ method: 'POST', url: 'https://airbnb.com/', data: { name: 'John' } }).done(() => console.log('Congratulations!')).fail(() => console.log('You have failed this city.'));

// Good
const foo = jsonData
  && jsonData.foo
  && jsonData.foo.bar
  && jsonData.foo.bar.baz
  && jsonData.foo.bar.baz.quux
  && jsonData.foo.bar.baz.quux.xyzzy;

// Good
$.ajax({
  method: 'POST',
  url: 'https://airbnb.com/',
  data: { name: 'John' },
})
  .done(() => console.log('Congratulations!'))
  .fail(() => console.log('You have failed this city.'));

20. カンマ（comma）

20.1 【スタイル】カンマを行頭に置かないこと。

eslint: comma-style
jscs: requireCommaBeforeLineBreak

// Bad
const story = [
    once
  , upon
  , aTime
];

// Good
const story = [
  once,
  upon,
  aTime,
];

// Bad
const hero = {
    firstName: 'Ada'
  , lastName: 'Lovelace'
  , birthYear: 1815
  , superPower: 'computers'
};

// Good
const hero = {
  firstName: 'Ada',
  lastName: 'Lovelace',
  birthYear: 1815,
  superPower: 'computers',
};

20.2 【スタイル】リスト末尾のカンマ（ケツカンマ）は省略しないこと。

eslint: comma-dangle
jscs: requireTrailingComma

理由: git diffの表示を見やすくするため。また、末尾カンマはBabelなどのトランスパイラでは削除されるため、実際にはレガシブラウザでのケツカンマ問題についての心配は不要。

// Bad - ケツカンマなしのgit diff
const hero = {
     firstName: 'Florence',
  -    lastName: 'Nightingale'
+    lastName: 'Nightingale',
+    inventorOf: ['coxcomb chart', 'modern nursing']
};

// Good - ケツカンマありのgit diff
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',
];

// Bad
function createHero(
  firstName,
  lastName,
  inventorOf
) {
  // does nothing
}

// Good
function createHero(
  firstName,
  lastName,
  inventorOf,
) {
  // does nothing
}

// Good （'...'の要素にはカンマをつけてはいけないことに注意）
function createHero(
  firstName,
  lastName,
  inventorOf,
  ...heroArgs
) {
  // does nothing
}

// Bad
createHero(
  firstName,
  lastName,
  inventorOf
);

// Good
createHero(
  firstName,
  lastName,
  inventorOf,
);

// Good （'...'の要素にはカンマをつけてはいけないことに注意）
createHero(
  firstName,
  lastName,
  inventorOf,
  ...heroArgs
);

21. セミコロン（semicolon）

21.1 【スタイル】セミコロンは省略しないこと。

eslint: semi
jscs: requireSemicolons

// Bad
(function () {
  const name = 'Skywalker'
  return name
})()

// Good
(function () {
  const name = 'Skywalker';
  return name;
}());

// Goodだが古い（即時関数式を使っている2つのファイルが結合された場合に関数が引数として扱われるのを防ぐ）
;((() => {
  const name = 'Skywalker';
  return name;
})());

詳しい解説

22. 型変換（type casting）と強制（coercion）

22.1 【推奨】文頭で強制型変換（type coercion）を行うこと。

22.2 文字列の場合:

// => this.reviewScore = 9;

// Bad
const totalScore = this.reviewScore + ''; // this.reviewScore.valueOf()が呼ばれる

// Bad
const totalScore = this.reviewScore.toString(); // 文字列が返されることは保証されない

// Good
const totalScore = String(this.reviewScore);

22.3 【必須】数値の場合: `Number`で型変換し、文字列をパースするときは常に`parseInt`で基数を指定すること。

eslint: radix

const inputValue = '4';

// Bad
const val = new Number(inputValue);

// Bad
const val = +inputValue;

// Bad
const val = inputValue >> 0;

// Bad
const val = parseInt(inputValue);

// Good
const val = Number(inputValue);

// Good
const val = parseInt(inputValue, 10);

22.4 【必須】パフォーマンス上の理由でビットシフトを使いたい、`parseInt`がボトルネックになるなどの名目で荒っぽくやりたい場合、理由のいかんを問わず、自分がどんな理由で何をしようとしているのかをコメントにはっきり書き残すこと。

// Good
/**
 * parseIntが原因でコードの実行が遅かった。
 * StringをビットシフトしてNumberに強制型変換したことで
 * 速度を大きく改善できた。
 */
const val = inputValue >> 0;

22.5 【必須】注: ビットシフト操作にはくれぐれも注意すること。JavaScriptの数値は64ビット値で表されるが、ビットシフトすると常に32ビット整数が返る（参照）。32ビットを超える整数をビットシフトすると思わぬ挙動が発生することがある（議論）。符号付き32ビット整数の最大値は`2,147,483,647`になる。

2147483647 >> 0; // => 2147483647
2147483648 >> 0; // => -2147483648
2147483649 >> 0; // => -2147483647

22.6 【推奨】Booleanの場合:

const age = 0;

// Bad
const hasAge = new Boolean(age);

// Good
const hasAge = Boolean(age);

// ベスト
const hasAge = !!age;

23. 命名規則（naming convention）

23.1 【スタイル】1文字の名前は避け、意味のある名前をつけること。

eslint: id-length

// Bad
function q() {
  // ...
}

// Good
function query() {
  // ...
}

23.2 【スタイル】オブジェクト名、関数名、インスタンス名は小文字で始まるキャメルケース（例: camelCase）にすること。

eslint: camelcase
jscs: requireCamelCaseOrUpperCaseIdentifiers

// Bad
const OBJEcttsssss = {};
const this_is_my_object = {};
function c() {}

// Good
const thisIsMyObject = {};
function thisIsMyFunction() {}

23.3 【スタイル】大文字で始まるキャメルケース（=パスカルケース）は、コンストラクタ名とクラス名以外では使わないこと（例: PascalCaseなど）。

eslint: new-cap
jscs: requireCapitalizedConstructors

// Bad
function user(options) {
  this.name = options.name;
}

const bad = new user({
  name: 'nope',
});

// Good
class User {
  constructor(options) {
    this.name = options.name;
  }
}

const good = new User({
  name: 'yup',
});

23.4 【非推奨】名前の最初や最後にアンダースコア`_`を付けないこと。

eslint: no-underscore-dangle
jscs: disallowDanglingUnderscores

理由: JavaScriptでは、プロパティやメソッドをprivateにするという概念が完全に欠落している。名前の冒頭に_を付けてprivateであることを示すコーディング規則は広く見られるが、実際にはプロパティは完全にpublicであり、publicなAPI規約の一部となる。名前の冒頭に_を付ける慣習に従うと、「変更しても影響ない」「テスト不要」などと開発者の誤解を招く可能性がある。どうしてもprivateにしたいものがあるなら、観測にかからないよう存在を消すしかない（ジョーク）。

// Bad
this.__firstName__ = 'Panda';
this.firstName_ = 'Panda';
this._firstName = 'Panda';

// Good
this.firstName = 'Panda';

23.5 【禁止】参照を`this`に保存しないこと。代わりにアロー関数かFunction#bindを使うこと。

jscs: disallowNodeTypes

// Bad
function foo() {
  const self = this;
  return function () {
    console.log(self);
  };
}

// Bad
function foo() {
  const that = this;
  return function () {
    console.log(that);
  };
}

// Good
function foo() {
  return () => {
    console.log(this);
  };
}

23.6 【必須】拡張子を除いたファイル名は、デフォルトの`export`の名前と（大文字小文字とアンダースコアも含め）完全に一致させること。

// ファイル1の内容
class CheckBox {
  // ...
}
export default CheckBox;

// ファイル2の内容
export default function fortyTwo() { return 42; }

// ファイル3の内容
export default function insideDirectory() {}

// その他のファイル
// Bad
import CheckBox from './checkBox'; // import/exportはパスカルケースだがファイル名がキャメルケース
import FortyTwo from './FortyTwo'; // importとファイル名はパスカルケースだがexportはキャメルケース
import InsideDirectory from './InsideDirectory'; // importとファイル名はパスカルケースだがexportはキャメルケース

// Bad
import CheckBox from './check_box'; // import/exportはパスカルケースだがファイル名がスネークケース
import forty_two from './forty_two'; // importとファイル名はスネークケースだがexportがキャメルケース
import inside_directory from './inside_directory'; // importはスネークケースだがexportはキャメルケース
import index from './inside_directory/index'; // indexファイルを明示的に必須にしている
import insideDirectory from './insideDirectory/index'; // indexファイルを明示的に必須にしている

// Good
import CheckBox from './CheckBox'; // export/import/filenameをパスカルケースで統一
import fortyTwo from './fortyTwo'; // export/import/filenameをキャメルケースで統一
import insideDirectory from './insideDirectory'; // export/import/ディレクトリ名/暗黙の"index"をキャメルケースで統一
// ^ この場合insideDirectory.jsとinsideDirectory/index.jsを両方ともサポートする

23.7 【必須】関数のデフォルトexportはキャメルケースにし、ファイル名と関数名を完全に一致させること。

function makeStyleGuide() {
  // ...
}

export default makeStyleGuide;

23.8 【スタイル】コンストラクタ、クラス、シングルトン、関数ライブラリ、生のオブジェクトをexportするときはパスカルケースにすること。

const AirbnbStyleGuide = {
  es6: {
  },
};

export default AirbnbStyleGuide;

23.9 【スタイル】略語や頭字語は、すべて大文字か、すべて小文字のどちらかに統一すること。

理由: 読みやすさのためであり、コンピュータアルゴリズム上の要請ではない。

// Bad
import SmsContainer from './containers/SmsContainer';

// Bad
const HttpRequests = [
  // ...
];

// Good
import SMSContainer from './containers/SMSContainer';

// Good
const HTTPRequests = [
  // ...
];

// ベスト
import TextMessageContainer from './containers/TextMessageContainer';

// ベスト
const Requests = [
  // ...
];

24. アクセサ（accessor）

24.1 【非推奨】プロパティ用のアクセサ関数は必須ではないことに注意する。

24.2 【非推奨】JavaScriptでゲッター/セッターを使わないこと。思わぬ副作用が生じる可能性があり、テストやメンテナンスも困難になるうえ、理解しづらくなる。どうしてもアクセサ関数が必要なら、`getVal()`や`setVal()`のような形式にすること。

// Bad
class Dragon {
  get age() {
    // ...
  }

  set age(value) {
    // ...
  }
}

// Good
class Dragon {
  getAge() {
    // ...
  }

  setAge(value) {
    // ...
  }
}

24.3 【非推奨】プロパティやメソッドが`boolean`の場合は`isVal()`や`hasVal()`のような名前にすること。

// Bad
if (!dragon.age()) {
  return false;
}

// Good
if (!dragon.hasAge()) {
  return false;
}

24.4 【非推奨】`get()`関数や`set()`関数を作成するなら、そのスタイルで統一すること。

class Jedi {
  constructor(options = {}) {
    const lightsaber = options.lightsaber || 'blue';
    this.set('lightsaber', lightsaber);
  }

  set(key, val) {
    this[key] = val;
  }

  get(key) {
    return this[key];
  }
}

25. イベント（event）

25.1 【推奨】データのペイロードをイベント（DOMイベント、またはBackboneイベントのような独自のもの）に追加する場合、生の値を渡さずにハッシュで渡すこと。こうすることで、後に改修する人がイベントペイロードに追加するデータを増やしたときに、イベントの全ハンドラを調べて更新しなくて済むようになる。たとえば、以下のように書かないこと。

// Bad
$(this).trigger('listingUpdated', listing.id);

// ...

$(this).on('listingUpdated', (e, listingId) => {
  // listingIdで何かする
});

次のように書くのが望ましい。

// Good
$(this).trigger('listingUpdated', { listingId: listing.id });

// ...

$(this).on('listingUpdated', (e, data) => {
  // data.listingIdで何かする
});

26. jQuery

26.1 【スタイル】jQueryのオブジェクト変数の冒頭には`$`を付けること。

jscs: requireDollarBeforejQueryAssignment

// Bad
const sidebar = $('.sidebar');

// Good
const $sidebar = $('.sidebar');

// Good
const $sidebarBtn = $('.sidebar-btn');

訳注: これはスタイル統一の指示であり、$の有無はプログラム上は影響しません。

26.2 【推奨】jQueryでは探索（lookup）をキャッシュしてから使うこと。

// Bad
function setSidebar() {
  $('.sidebar').hide();

  // ...

  $('.sidebar').css({
    'background-color': 'pink',
  });
}

// Good
function setSidebar() {
  const $sidebar = $('.sidebar');
  $sidebar.hide();

  // ...

  $sidebar.css({
    'background-color': 'pink',
  });
}

訳注: キャッシュしないと毎回探索が発生し、パフォーマンスが落ちます。

26.3 【推奨】DOMクエリではカスケード（`$('.sidebar ul')`）か「parent > child `$('.sidebar > ul')`」を使うこと（参考: jsPerf）。

26.4 【推奨】`find`でjQueryオブジェクトへのクエリにスコープを指定すること【TBD: 以下の不可と良好の違いがよくわからない】。

// Bad
$('ul', '.sidebar').hide();

// Bad
$('.sidebar').find('ul').hide();

// Good
$('.sidebar ul').hide();

// Good
$('.sidebar > ul').hide();

// Good
$sidebar.find('ul').hide();

1〜8: 型、参照、オブジェクト、配列、関数ほか
9〜14: クラス、モジュール、イテレータ、プロパティ、変数、巻き上げ
15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか -- 本記事

JavaScriptスタイルガイド 15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか （翻訳）

概要

凡例

JavaScriptスタイルガイド 15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか （翻訳）

15. 比較演算子と相等条件

15.1 【必須】===や!==を使うこと。【禁止】==や!=は使わないこと。

15.2 【知識】if文などの条件文では、ToBoolean抽象メソッドで強制的に式を評価する。評価のルールは常に以下に従うことに注意。

15.3 【推奨】boolean値については演算子を使わない省略記法を使うこと。ただし文字列同士や数値同士の比較は明示的に演算子を使うこと。

15.4 【知識】詳しくはTruth Equality and JavaScript（Angus Croll）を参照。

15.5 【推奨】case句やdefault句のレキシカル（静的）な宣言（let、const、function、classなど）は波かっこ{ }で囲んでブロックを作成すること。

15.6 【禁止】三項演算子はネストするべきではない。【推奨】三項演算子は1行で書く式として用いる（複数行に分けない）のが一般的。

15.7 【非推奨】三項演算子の乱用は避ける（不要な三項演算子を使わない）。

16. ブロック（block）

16.1 【スタイル】ブロックは複数行形式の波かっこ{ }にすること（ブロックを1行で書かない）。

16.2 【スタイル】ifとelseを使う複数行ブロックでは、elseと同じ行でifのブロックを閉じること。

17. 制御文（control statement）

17.1 【選択】ifやwhileなどの制御文が1行の最大文字数を超える場合は、各条件を1行ずつに分けてよい。論理演算子を条件行の冒頭に置くか末尾に置くかはどちらに決めてもよい。

18. コメント（comment）

18.1 【スタイル】複数行コメントは/** ... */で書くこと

18.2 【スタイル】1行コメントは//を使い、コメント対象行のすぐ上に書くこと。1行コメントの上は空行にすること（ブロックの1行目にコメントする場合を除く）。

18.3 【スタイル】可読性のため、コメント記号とコメント文冒頭の間にスペースを1つ置くこと。

18.5 【推奨】問題点の指摘には// FIXME:を使うこと。

18.6 【推奨】問題の解決方法の指示には// TODO:を使うこと。

19. スペース（whitespace）

19.1 【スタイル】ソフトタブはスペース2文字のものを使うこと。

19.2 【スタイル】開始波かっこ{の直前にはスペースを1つ置くこと。

19.3 【スタイル】ifやwhileなどの制御文で使われる開始丸かっこ(の前にはスペースを1文字置くこと。引数リストで使われる開始丸かっこ(と、関数呼び出しや関数宣言の関数名との間にはスペースを置かないこと。

19.4 【スタイル】演算子の前後にはスペースを1つ置くこと。

19.5 【スタイル】ファイルの末尾には改行文字を1つだけ置くこと。

19.6 【スタイル】メソッドチェーンが3つ以上になる場合はインデントすること。その場合ドット.はメソッド名の（末尾ではなく）冒頭に付けて、その行が新しい文ではなくメソッド呼び出しであることを示す。

19.7 【スタイル】ブロックと次の文の間は1行空けること。

19.8 【スタイル】波かっこ{ }ブロックのすぐ内側に空行を置かないこと。

19.9 【スタイル】丸かっこ( )の内側にスペースを置かないこと。

19.10 【スタイル】角かっこ[ ]の内側にスペースを置かないこと。

19.11 【スタイル】波かっこ{ } の内側にはスペースを置くこと。

19.12 【スタイル】1行あたりの文字数が100文字（スペースを含む）を超えることは避ける。**注:* 上述のとおり、長い文字列はこのルールの適用範囲外であり、長い文字列を分割すべきではない。

20. カンマ（comma）

20.1 【スタイル】カンマを行頭に置かないこと。

20.2 【スタイル】リスト末尾のカンマ（ケツカンマ）は省略しないこと。

21. セミコロン（semicolon）

21.1 【スタイル】セミコロンは省略しないこと。

22. 型変換（type casting）と強制（coercion）

22.1 【推奨】文頭で強制型変換（type coercion）を行うこと。

22.2 文字列の場合:

22.3 【必須】数値の場合: Numberで型変換し、文字列をパースするときは常にparseIntで基数を指定すること。

22.6 【推奨】Booleanの場合:

23. 命名規則（naming convention）

23.1 【スタイル】1文字の名前は避け、意味のある名前をつけること。

23.2 【スタイル】オブジェクト名、関数名、インスタンス名は小文字で始まるキャメルケース（例: camelCase）にすること。

23.3 【スタイル】大文字で始まるキャメルケース（=パスカルケース）は、コンストラクタ名とクラス名以外では使わないこと（例: PascalCaseなど）。

23.4 【非推奨】名前の最初や最後にアンダースコア_を付けないこと。

23.5 【禁止】参照をthisに保存しないこと。代わりにアロー関数かFunction#bindを使うこと。

23.6 【必須】拡張子を除いたファイル名は、デフォルトのexportの名前と（大文字小文字とアンダースコアも含め）完全に一致させること。

23.7 【必須】関数のデフォルトexportはキャメルケースにし、ファイル名と関数名を完全に一致させること。

23.8 【スタイル】コンストラクタ、クラス、シングルトン、関数ライブラリ、生のオブジェクトをexportするときはパスカルケースにすること。

23.9 【スタイル】略語や頭字語は、すべて大文字か、すべて小文字のどちらかに統一すること。

24. アクセサ（accessor）

24.1 【非推奨】プロパティ用のアクセサ関数は必須ではないことに注意する。

24.3 【非推奨】プロパティやメソッドがbooleanの場合はisVal()やhasVal()のような名前にすること。

24.4 【非推奨】get()関数やset()関数を作成するなら、そのスタイルで統一すること。

25. イベント（event）

26. jQuery

26.1 【スタイル】jQueryのオブジェクト変数の冒頭には$を付けること。

26.2 【推奨】jQueryでは探索（lookup）をキャッシュしてから使うこと。

26.3 【推奨】DOMクエリではカスケード（$('.sidebar ul')）か「parent > child $('.sidebar > ul')」を使うこと（参考: jsPerf）。

26.4 【推奨】findでjQueryオブジェクトへのクエリにスコープを指定すること【TBD: 以下の不可と良好の違いがよくわからない】。

関連記事（JavaScript）

週刊Railsウォッチ（20191202前編）Rails 6のimplicit_order_columnはカスタマイズ可能、rubocop-rails 2.4.0リリース、Capistrano記事ほか

Kotlinの拡張機能で冗長な〇〇Utilsから脱却する

Rails: ビューでstrftimeを直書きするのはたぶんよくない（翻訳）

週刊Railsウォッチ（20191119後編）メソッド参照演算子が廃止、GitHub新機能続々、平成Ruby会議、GitHub OAuthバイパスほか

Rails 6の新しいデフォルト設定と安全な移行方法を詳しく解説（翻訳）

Vue.jsサンプルコード（29）フィールドごとに全角英数字入力と半角英数字入力を自動で切り替える

AndroidのTextViewへHTMLマークアップによるスタイル設定（文字列装飾）を行う

電子書籍でよく耳にする「EPUB」っていったい何者？なんて読むの？非エンジニアが簡単にまとめてみた

EclipseでJavaソースから参照されているjarファイルの場所を探す

便利なepubcheckを使ってみよう（上） 使い方編

ISO8601を用いて時間を正確に表現しよう

MinIOを導入して使ってみた話

RailsでDBのtime型同士を比較する際の注意点

JavaScriptスタイルガイド 15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか（翻訳）

JavaScriptスタイルガイド 15〜26: 比較演算子、ブロック、制御文、型変換、命名規則ほか（翻訳）

15.1 【必須】`===`や`!==`を使うこと。
【禁止】`==`や`!=`は使わないこと。

15.2 【知識】`if`文などの条件文では、`ToBoolean`抽象メソッドで強制的に式を評価する。評価のルールは常に以下に従うことに注意。

15.5 【推奨】`case`句や`default`句のレキシカル（静的）な宣言（`let`、`const`、`function`、`class`など）は波かっこ`{ }`で囲んでブロックを作成すること。

15.6 【禁止】三項演算子はネストするべきではない。
【推奨】三項演算子は1行で書く式として用いる（複数行に分けない）のが一般的。

16.1 【スタイル】ブロックは複数行形式の波かっこ`{ }`にすること（ブロックを1行で書かない）。

16.2 【スタイル】`if`と`else`を使う複数行ブロックでは、`else`と同じ行で`if`のブロックを閉じること。

17.1 【選択】`if`や`while`などの制御文が1行の最大文字数を超える場合は、各条件を1行ずつに分けてよい。論理演算子を条件行の冒頭に置くか末尾に置くかはどちらに決めてもよい。

18.1 【スタイル】複数行コメントは`/** ... */`で書くこと

18.2 【スタイル】1行コメントは`//`を使い、コメント対象行のすぐ上に書くこと。1行コメントの上は空行にすること（ブロックの1行目にコメントする場合を除く）。

18.5 【推奨】問題点の指摘には`// FIXME:`を使うこと。

18.6 【推奨】問題の解決方法の指示には`// TODO:`を使うこと。

19.2 【スタイル】開始波かっこ`{`の直前にはスペースを1つ置くこと。

19.3 【スタイル】`if`や`while`などの制御文で使われる開始丸かっこ`(`の前にはスペースを1文字置くこと。引数リストで使われる開始丸かっこ`(`と、関数呼び出しや関数宣言の関数名との間にはスペースを置かないこと。

19.6 【スタイル】メソッドチェーンが3つ以上になる場合はインデントすること。その場合ドット`.`はメソッド名の（末尾ではなく）冒頭に付けて、その行が新しい文ではなくメソッド呼び出しであることを示す。

19.8 【スタイル】波かっこ`{ }`ブロックのすぐ内側に空行を置かないこと。

19.9 【スタイル】丸かっこ`( )`の内側にスペースを置かないこと。

19.10 【スタイル】角かっこ`[ ]`の内側にスペースを置かないこと。

19.11 【スタイル】波かっこ`{ }` の内側にはスペースを置くこと。

22.3 【必須】数値の場合: `Number`で型変換し、文字列をパースするときは常に`parseInt`で基数を指定すること。

23.4 【非推奨】名前の最初や最後にアンダースコア`_`を付けないこと。

23.5 【禁止】参照を`this`に保存しないこと。代わりにアロー関数かFunction#bindを使うこと。

23.6 【必須】拡張子を除いたファイル名は、デフォルトの`export`の名前と（大文字小文字とアンダースコアも含め）完全に一致させること。

24.3 【非推奨】プロパティやメソッドが`boolean`の場合は`isVal()`や`hasVal()`のような名前にすること。

24.4 【非推奨】`get()`関数や`set()`関数を作成するなら、そのスタイルで統一すること。

26.1 【スタイル】jQueryのオブジェクト変数の冒頭には`$`を付けること。

26.3 【推奨】DOMクエリではカスケード（`$('.sidebar ul')`）か「parent > child `$('.sidebar > ul')`」を使うこと（参考: jsPerf）。

26.4 【推奨】`find`でjQueryオブジェクトへのクエリにスコープを指定すること【TBD: 以下の不可と良好の違いがよくわからない】。

便利なepubcheckを使ってみよう（上）　使い方編

「GitLabに学ぶ世界最先端のリモート組織のつくりかた」を読んでメンバーとしてできることを考えてみた

JavaScriptスタイルガイド 1〜8: 型、参照、オブジェクト、配列、関数ほか（翻訳）