チーム開発に効く環境構築術 | 第1回 EditorConfigのススメ

チーム開発に効く環境構築術第1回 EditorConfigのススメ

エディタのインデントや文字コード、改行コードなどを一括で設定し、異なるエディタ間でも共有できるEditorConfig。プロジェクトによって設定を変えたり、チームで開発環境を統一するのに重宝します。

カテゴリー: 開発ツール >; 開発環境

2015年4月23日発行

著者山田敬美フロントエンド・エンジニア

チーム開発に効く環境構築術シリーズの記事一覧

はじめに

EditorConfig（エディタコンフィグ）とは、インデントや文字コード、改行コードなどのコーディングスタイルに関するエディタの設定を、異なるエディタ間で共有するための規格です。

設定内容を記述した.editorconfigというファイルをプロジェクトのディレクトリに置いておくだけで、自動的にエディタの設定として反映されます。

EditorConfigを使うことによって、エディタの設定に起因する不要なトラブルを未然に防ぐことができます。

対応エディタ

EditorConfigに対応しているエディタは公式サイトで確認できますが、主要なエディタの多くが対応しています。

フロントエンドの開発で使われることの多い、次のエディタにも対応しています。

EditorConfigを使うメリット

エディタの設定をわざわざ外部ファイルで行うなんて、面倒だと感じるかもしれませんが、EditorConfigを使わない方がかえって面倒なことになる場合もあります。

複数の人が関わるプロジェクトの場合

プロジェクトの開発に複数人が関わる場合、それぞれのエディタの設定が異なっていると、改行コードや文字コードが意図せず変わってしまうことがあります。Gitでリソースを管理している場合などは、そのままコミットするとすべての行がDiffとなり、実際の変更箇所が埋もれてしまいます。また、同じプロジェクト内で、タブとスペースのインデントが混在するという状況にもなりかねません。

EditorConfigを使えば、エディタの設定を外部ファイルで管理できるため、このようなトラブルを防ぐことができます。プロジェクトごとに設定ファイルを用意して、Gitなどのバージョン管理システムで共有しておけば、設定の変更にも柔軟に対応できますし、プロジェクトに関わる全員が同じ設定で開発できるようになります。

また、設定ファイルを開くだけでコーディングスタイルがわかるため、簡易的なガイドライン代わりにもなります。

プロジェクトごとにコーディングスタイルが異なる場合

受託案件ではプロジェクトごとにコーディングスタイルが異なるケースがありますが、そのつどエディタの設定を手動でポチポチと変更するのはとても面倒です。さらに、複数の案件を同時進行で進めるとしたら、プロジェクトを切り替えるたびにエディタの設定を変更……なんてとてもやっていられません。

EditorConfigの設定ファイルをプロジェクトごとに用意して、プロジェクトのルートディレクトリに置いておけば、プロジェクトを切り替えるたびにエディタの設定が自動的に切り替わるため、手動で変更する手間がなくなります。

複数のエディタを使い分ける場合

状況によって複数のエディタを使い分けているような場合、エディタごとに設定を行うのは面倒です。

EditorConfigに対応しているエディタ同士であれば、設定ファイルをひとつ用意しておくだけで済みます。

コラム：EditorConfigの利用例

筆者の場合は、ある受託案件では文字コードはShift_JIS、改行コードはCRLF、インデントはタブインデントというルールです。しかし、個人でコードを書く場合はUTF-8、LF、2スペースインデントが好みですし、ときどき手伝う別案件も、個人でコードを書く場合と同じルールという状況です。

また、前者の案件の中でも、HTMLとCSSはタブインデント、JavaScriptは2スペースインデントといった具合に、ひとつのプロジェクトの中でもファイルの種類によってルールが分かれています。

作業するプロジェクトや作業ファイルを切り替えるたびにエディタの設定を変更するのは非現実的で、エディタがファイルを解析して、よしなに設定してくれる機能に頼っていたのですが、場合によってはインデントにタブとスペースが混在したり、改行コードが変わってしまうこともありました。

また、外部の人に作業を依頼するときにコーディングスタイルを伝え忘れてしまったりなどトラブルもありました。

しかし、EditorConfigを使うようになってからは、どんなコーディングスタイルでもどんとこいという気持ちで、無駄な気苦労をすることなく開発に専念できるようになりました。

EditorConfigの使い方

EditorConfigは、エディタのプラグインとして動作するため、まず最初にエディタにEditorConfigプラグインをインストールしておく必要があります。

EditorConfigプラグインが入っていないと、プロジェクトで設定ファイルが共有されていても、エディタにはその設定が反映されないため、とりあえずプラグインだけでも入れておくとよいでしょう。

EditorConfigプラグインのインストール

公式サイトのエディタのアイコンをクリックすると、インストール方法が記載されたページが表示されるので、手順に沿ってEditorConfigプラグインをインストールします。

設定ファイルの作成

.editorconfigという名前のテキストファイルを作成します。ファイルの文字コードはUTF-8、改行コードはCRLFかLFである必要があります。

EditorConfigは、エディタで開いたファイルの置かれているディレクトリから上の階層に向かって.editorconfigを探索していく*ため、プロジェクトのルートディレクトリに.editorconfigを保存します。

*注：`.editorconfig`の探索

.editorconfigが見つからない場合は、最終的にルートディレクトリまで遡って見てくれるので、ユーザールートディレクトリに基本的な設定を記述した.editorconfigを置いておくのもよいでしょう。

設定ファイルの記述方法

.editorconfigには次のように、ファイルの種類ごとにコーディングスタイルの設定をそれぞれ記述していきます。[ ]内にファイルの種類を指定します。

基本的な書式はプロパティ名 = 値です。値のアルファベットは大文字、小文字を区別しません。

[*]
indent_style = space
indent_size = 2
end_of_line = lf

[*.html]
indent_style = tab

ファイルの指定

.editorconfigでは、ワイルドカードを使ってファイル名を指定できます。

使用できる記号は次のとおりです。

記号	説明	サンプル	使用頻度
`*`	`/`（パス区切り文字）を除く任意の文字列	`[*.js]`	高
`**`	特定ディレクトリの任意の文字列	`[libs/**.js]`	高
`?`	任意の1文字	-	低
`[name]`	ファイル名`name`	`[package.json]`	高
`[!name]`	ファイル名`name`以外	`[!package.json]`	低
`{s1,s2,s3}`	ファイル名`s1` `s2` `s3`のいずれか	`[{.eslintrc,.json,.yml}]`	中

これらを組み合わせることで、拡張子の種類ごとに設定内容を指定したり、特定のディレクトリにあるファイルや、特定のファイル名だけに絞って指定することもできます。

特定のディレクトリを指定しない場合は、プロジェクト内すべてのディレクトリにあるファイルが対象となります。

コーディングスタイルの設定

指定できるプロパティは次のとおりですが、すべてを指定する必要はなく、必要なものだけを指定すれば大丈夫です。なお、未指定のプロパティについては、エディタ自身の設定が適用されます。

プロパティ	値
`root`	`true` \| `false`
`indent_style`	`tab` \| `space`
`indent_size`	Integer（整数） \| `tab`
`tab_width`	A Positive Integer（正の整数）
`end_of_line`	`lf` \| `cr` \| `crlf`
`charset`	`latin1` \| `utf-8` \| `utf-8-bom` \| `utf-16be` \| `utf-16le`
`trim_trailing_whitespace`	`true` \| `false`
`insert_final_newline`	`true` \| `false`

次にそれぞれのプロパティの意味を解説します。

root

trueに設定することで、上位階層の.editorconfigを探索しなくなります。

.editorconfigの保存先がプロジェクトのルートディレクトリの場合はtrueに設定します。

indent_style

インデントの種類を指定します。

tabかspaceのみ指定可能です。

indent_size

1インデントの幅を数値で指定します。数値は半角スペースの文字数を表します。例えば、2と指定すれば、1インデントの幅は半角スペース2つ分になります。indent_sizeの値にtabを指定した場合は、tab_widthで設定した値が使用されます。

tab_width

インデントがタブの場合の、1インデントの幅を正の整数で指定します。

ただし、indent_sizeが指定されている場合は、その値がデフォルト値となるため、tab_widthを重複して指定する必要はありません。

end_of_line

改行コードを指定します。

lf、cr、crlfのいずれかを指定できます。

charset

文字コードを指定します。

EditorConfigが公式にサポートしていると公言しているのは、latin1、utf-8、utf-8-bom（非推奨）、utf-16be、utf-16leのみです。日本国内で通常使われるのは、この中だとutf-8だけ*でしょう。

コラム：サポート外の文字コードを指定した場合の挙動

EditorConfigの仕様書では、プラグイン開発者に、EditorConfigの仕様にないプロパティや値は、すべて無視するようにプラグインを設計してほしいと要請しています（公式サイトの「Create a plugin」参照）。将来的に新しいプロパティが追加された際に互換性を保つためです。

日本国内でしばしば使われるcharset = shift_jisなど、未対応の文字コードを指定した場合も、このルールにしたがってshift_jisは適用されず、エディタの設定が適用されました（調査した限りではSublime Text、Vimなど）。

ただ、2015年4月現在、Atomの実装はやや異なっており、.editorconfigで指定された文字コードをそのまま適用していました。このように、サポート外の文字コードを指定した.editorconfigでは、意図したようにフォーマットを統一できない問題があります。

.editorconfigで設定した文字コードがファイルに適用されるタイミングは、保存時やオープン時などエディタによって異なります。

なお、新規ファイル作成においては、エディタのツリービュー上で新規作成するか、プロジェクトのディレクトリ以下でファイルを作成してからエディタで開くようにするほうがよいでしょう。メニューから新規作成（⌘+N、Ctrl+N）したファイルは作成時点では保存先が不明なため、.editorconfigの設定ではなく、エディタで設定している文字コードが適用されてしまいます。

trim_trailing_whitespace

trueに設定することで、行末（改行コードの前）にある空白文字（スペースやタブ）を削除します。

通常はtrueにしておくことでコードがクリーンに保たれますが、Markdownの場合は、行末の2スペースは改行という意味があるため、少なくとも[.md]はfalseに設定することをおすすめします*。

*注：trim_trailing_whitespaceのfalseの設定

Markdownの書式は.mdファイルだけでなく、YAMLなどにも文字列として含まれることがあります。そのような場合にも、trim_trailing_whitespaceをfalseにする必要があるでしょう。

insert_final_newline

最後の行に空行を入れます。

trueに設定して、最後の行は空行にするのが一般的です。

サンプルコード

例として、bowerの.editorconfigを見てみましょう。次のように指定されています。

root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

[**.std]
insert_final_newline = false

[{package,bower}.json]
indent_style = space
indent_size = 2

[*]ですべてのファイルに対して基本的な設定をしたあと、[*.md]などの個別のファイルに対して設定を上書きしています。

ほかにもいろいろなプロジェクトの.editorconfigがProjects Using EditorConfig · editorconfig/editorconfig Wikiから見ることができるので、参考にしてみてください。

設定ファイルのひな形

このほか、筆者が普段設定している.editorconfigのサンプルコードを掲載しておきます。

所属するプロジェクトのルールに合った設定に修正してご活用ください。

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

このように[*]でベーススタイルを設定する方法は、ファイル種別ごとに個別に設定する必要がないため記述が楽です。また、設定漏れが発生しないというメリットがあります。

反面、ベーススタイルと異なるコーディングルールのファイルに対して個別の上書き設定を忘れてしまうと、意図せぬ設定が適用されてしまうことにもなります。

そのため、ベースの設定は最低限の項目に留めておき、ファイル種別ごとの個別の設定で細かな設定をしていく方法がベストではないかと筆者は考えます。

EditorConfig導入時の注意点

このように便利なEditorConfigではありますが、その反面、知らない間に誰かに.editorconfigファイルを置かれてしまうと、勝手に自分のエディタの設定を変えられてしまうということにもなります。

例えば、何かのテストであえてルールと異なるコーディングスタイルで作成していたファイルが、.editorconfigを勝手に追加されたことで、書き換わってしまうこともありえます。

途中からEditorConfigを導入するような場合は、念のため、同じチームのメンバーに確認をとってから設定するとよいでしょう。

まとめ

複数人が関わるプロジェクトでは、リポジトリに.editorconfigを置いてエディタ設定を共有することで、エディタ設定に起因する不要なトラブルを避けられ、全員が気持ちよく開発に専念できるようになります。

ただし、EditorConfigを使っている人がいたりいなかったりの状態では意味がないので、環境を統一する意図があるならば、ぜひEditorConfigプラグインのインストールだけでもしてみてください。