JavaScript Standard Styleのススメ

JavaScriptのコーディングスタイル(コーディング規約)の1つ、JavaScript Standard Styleについて紹介します。

「Standard」という名前ですが、JavaScript公式のルールではありません。有志によって提唱されたコーディングスタイルの1つです。個人的には、そのような挑戦的なところもお気に入りポイントの1つです。

コーディングスタイルとは?

読みやすいコードを書くためのルール

プログラマは日々、自らの書くコードを読みやすいものにするため、様々な工夫を行っています。

  • インデントやスペースを入れる
  • 変数の名前を工夫する
  • バグを生みやすい構文を避ける
  • …etc…

このようなスタイルは、書き手の経験や好みが色濃く反映されます。ところどころで宗教戦争も勃発しています。そこで、書き手によって差が出ないように、スタイルをルール化したものがコーディングスタイルです。

チーム開発ではルールの統一が重要

特に、チームで開発プロジェクトに従事する場合にはコーディングスタイルが重要です。

プログラムは開発中も完成した後も、修正や再利用が発生します。そのため、後でコードを読み返すということが頻繁に起こります。

その作業は、書いた本人ではないプログラマが行うことも珍しくありませんし、日々、数百行ものコードを記述する中で、わずかでも期間が空くと、書いた本人であってもすぐ他者と同じレベルに落ちます。

他者のコードを読むのはそれだけでも大変な作業ですが、スタイルの一貫性が無いと、「あっちのファイルではこうだったのに、こっちのファイルは全然違う…」と、読む側も頭のスイッチを切り替えなければならず、さらに時間と体力を消費します。

コードレビューは重要な工程ですが、そのレビュアーも同じで、他者のコードを評価するお仕事なので、スタイルを統一してコードリーディングの負担を軽減したほうが、よりスムーズに進められます。

導入方法は「作る」か「もらう」か

コーディングスタイルの導入方法は、独自のものを作るか、既にあるものを取り入れるかのどちらかです。独自のコーディングスタイルを使っている組織、チームも多いと思います。

この記事で紹介するJavaScript Standard Styleのような、広く公開されているコーディングスタイルをそのまま取り入れるというのも可能です。肌に合うかどうかという問題はありますが、作る手間は省けます。

なお、JavaScript Standard Style以外で、個人的によく目にするコーディングスタイルは次の3つです。

JavaScript Standard Styleは「カスタマイズ済みESLint」

JavaScript Standard Styleは2015年にFeross Aboukhadijeh氏が提唱したコーディングスタイルで、メジャーな文法チェッカの1つである、ESLintのサブセットです。

ESLintでは、各ルールの詳細なカスタマイズが可能です。例えば、semiは行頭や行末のセミコロンの取扱いに関するルールですが、「必ず付す」というルールにもできますし、逆に「一切付さない」というルールにもできます。チェック対象にせず「どちらでもいい」という立場もあり、こういった設定を1つ1つ積み重ねていくと、独自のコーディングスタイルが出来上がります。

JavaScript Standard Styleは、これと同様にESLintの各ルールについて取扱いを決めた、いわゆる「カスタマイズ済みESLint」です。設定内容は固定されているので、カスタマイズは不可能です。

実際には、エディタなどで使用する際、一部のルールを上書きしてチェックさせることが可能となっていますが、何らかの変更を加えた時点で、それはJavaScript Standard Styleではない独自のコーディングスタイル、ということになるかと思います。

JavaScript Standard Styleの代表的なルール

すべてのルールは公式サイトで確認できますが、いくつか代表的なルールを紹介します。

インデントはスペース2つ

4つではなく2つです。タブも禁止です。

タブ派のプログラマも多く見かけますが、JavaScript Standard Styleではスペースに統一しています。

文字列リテラルは原則シングルクォーテーション

一部の例外を除いて、ダブルクォーテーションは使いません。バッククォートを使ったテンプレートリテラルは普通に使えます。

行末のセミコロン禁止

「セミコロンは必ず入れろ!」と厳しく指導された経験のある方も多いかもしれませんが、JavaScript Standard Styleではエラーになります。

セミコロンは省略すると問題となるケースがありますが、他のルールとの組み合わせでクリアしています。

==ではなく===を使う

一部の例外を除いて、比較の際の==を禁止します。

キャメルケースを使う

snake_caseのようなスネークケースは禁止で、snakeCase(変数や関数)またはSnakeCase(クラスやコンストラクタ)としなければなりません。

SNAKE_CASEのような、すべて大文字にする命名はOKです。定数でよく使われる書き方です。

適宜スペースを入れる(かつ、入れすぎない)

iffunction、関数名の後、forや括弧内のセミコロンの後、オブジェクトリテラルのコロンの前後、演算子の前後、カンマの後などで、スペースの入れ方が細かく決められています。入れすぎても怒られます。

/* NG */

if(condition) {
  // ...
}

const myFunc=function hoge(a,b) {
  // ...
}

/* OK */

if (condition) {
  // ...
}

const myFunc = function hoge (a, b) {
  // ...
}

スペースを入れて=を縦並びにする方もいます(個人的には嫌いじゃないです)が、これもJavaScript Standard Styleでは認められていません。

/* NG */
const a   = 150
const aa  = 200
const aaa = 250

/* OK */
const a = 150
const aa = 200
const aaa = 250

空行は1行まで

処理の固まりごとに区切るなどの目的で、空行を入れることがありますが、2行以上の空行を使うことはできません。

未使用の変数は禁止

使われていない変数があるとエラーが出ます。typoを見つける際にも役立ちます。

JavaScript Standard Styleの導入方法

普通、目視でのチェックはしません。リアルタイムで、またはトランスパイル時など、任意のタイミングで自動的にチェックしてもらえるように設定します。

.eslintrcはGitHubで入手可能

そのままESLintで使える設定ファイル、またはカスタマイズして独自スタイルを作るためのベースとなるファイルは、以下のGitHubリポジトリから入手することができます。

ESLint Config for JavaScript Standard Style. Contribute to eslint-config-standard development by creating an account on GitHub.

この設定を使ってESLintのチェックをパスすれば、JavaScript Standard Styleに準拠したJavaScriptだと名乗ることができます。

npmでパッケージを導入可能

npmでパッケージが公開されているので、開発環境にインストールして利用できます。

JavaScript Standard Style

単体のパッケージだけでなく、ESLint用のプラグインもあります。

eslint-plugin-standard - ESlint Rules for the Standard Linter

セミコロン必須の「JavaScript Semi-Standard Style」も

数あるルールの中で、最も受け入れられにくいルールは「セミコロン禁止」ではないかと思います。

他のコーディングスタイルを見ても、セミコロンは必須としている場合が多いですし、個人的にも導入してしばらく経ちますが、未だに癖で打ってしまうことがあります。

そこで、「セミコロン必須版」JavaScript Standard Styleとして、JavaScript Semi-Standard Styleも登場しています。「他のルールはいいけど、セミコロンだけはな…」という場合は、これを使うという選択ができるようになっています。

semistandard - :icecream: All the goodness of `feross/standard` with semicolons sprinkled on top.

まとめ

JavaScript Standard Styleに限らず、何らかのコーディングスタイルに基づいてプログラムを書くことは、読み手の負担を軽減するうえで、とても重要です。

今までスタイルを意識したことが無い、そういえば今まで書いたJavaScriptはバラバラだったな…という方は、ぜひこの機会に自分に合ったコーディングスタイルを探してみてください。