みなさんは普段JavaScriptを使って開発する場合、インデントはどのようにしていますか? タブ、スペース2個、スペース4個・・・などいくつかの選択肢があります。

個人で開発している方は問題ありませんが、チームで開発している場合は意見が分かれ議論になることもあるでしょう。プロジェクト開始早々インデント論争でチーム内の雰囲気を悪くしたくはありません。

本記事はそんなインデント論争の一つの解決策となるべく、ブラウザベンダーやプロダクトで定めているJavaScriptコーディングのインデントルールを調べてみました

なぜインデント論争が起こるのか?

そもそもなぜインデント論争が起こってしまうのでしょうか? それはそれぞれ一長一短のため好みが分かれてしまうからです。ここではインデントの種類毎のメリット・デメリットをご紹介します。

タブ

1512_js_indent_tab

メリット

  • 開発者が自分好みにインデント幅が変えられる
  • インデント移動時のキータイプが少ない

デメリット

  • 位置揃えとして使用すると環境によって崩れる

スペース

1512_js_indent_space

メリット

  • 環境に左右されず同じ見た目でソースが表示される

デメリット

  • 同じスペース派内でもスペースの数で派閥が生まれる

スペース派内の派閥

スペースのデメリットに挙げたように同じスペース派の中でもスペースをいくつ使うかで派閥が生じます。主に2個派、4個派、8個派のいずれかです。スペースが少ない場合は冗長にならずコードの折り返しが起こりにくく、スペースが多い場合は入れ子構造が把握しやすく可読性が高いといったそれぞれの長所があります。

JSコーディング規約のインデントルールを調べてみた

それでは世の中でどういった形のインデントが使用されているのか見ていくことにしましょう。

企業や組織のJSコーディング規約内のインデントルール

まずはブラウザベンダーを中心に、公開されているコーディング規約からインデントルールを抜粋し次の表にまとめました。

組織名インデントルールコーディング規約ページ
Mozillaスペース2個JavaScript style guide – Mozilla Developer Network
Googleスペース2個Google JavaScript Style Guide 和訳
WebKitスペース4個WebKit Coding Style Guidelines

JSライブラリ/JSフレームワークのインデントルール

続いてJavaScriptのライブラリやフレームワークで採用されているインデントルールを次の表にまとめました。尚、インデントルールはJSHintESLintなどの構文チェックツールの設定ファイルから抜粋しています。

プロダクト名インデントルール設定ファイル
Node.jsスペース2個.eslintrc
Reactスペース2個.eslintrc
Vue.jsスペース2個.eslintrc
Riot.jsスペース2個.eslintrc
Underscore.jsスペース2個.eslintrc
AngularJSスペース2個.jshintrc-base
Ember.jsスペース2個.jscsrc
lodashスペース2個.jscsrc
gulpスペース2個.editorconfig
Pixi.jsスペース4個.jshintrc
Moment.jsスペース4個.editorconfig
Mithril.jsタブ.eslintrc
jQueryタブ.editorconfig

※ .jshintrc, .eslintrc, .jscsrcは構文チェックの設定ファイルです。
※ .editorconfigはEditorConfigという開発者間でエディターの設定を共有できるツールの設定ファイルです。

海外のJS規約ではスペース2個のインデントが多く使われていた

1512_js_indent_graph

調査によるとインデントはスペース2個と定めている場合が多いようですね。

国内のインデント事情はタブが多数

インデント数について弊社池田がTwitterでアンケートを実施。このアンケートではプログラム言語を指定していないため、JavaScriptに限った回答ではありませんが、44%が「タブ」、33%が「スペース2つ」、23%が「スペース4つ」という結果になりました。海外のJavaScriptコーディング規約とは異なる傾向であり、興味深いですね。

アンケートについて、詳しくは記事「HTMLコーダーへのアンケート結果(コードの書き方)」で紹介してますので、あわせて参考ください。本記事はJavaScript界隈のインデントルールをほんの一部まとめたものに過ぎませんが、みなさんのプロジェクトの規約作成の際に参考にしていただけたら幸いです。