10分以内にVisual StudioでEditorconfigを使う

プロジェクトや開発者間で一貫したコーディングスタイルを維持することは、特に、Visual StudioやVisual Studio Codeのような異なるセットアップや環境設定、さらには異なるエディタを使用しているチームで作業する場合、しばしば課題となります。 動画"EditorConfig in Visual Studio in 10 Minutes or Less"では、ティム・コーリーがEditorConfigファイルによって、.NETプロジェクトでプロジェクト固有のコーディング規約を定義し、実施する方法を説明しています。

この記事では、EditorConfig C#の設定がコードのスタイル、インデント、構造の統一性を維持するためにどのように役立つかを示しながら、Timが説明するコンセプトを正確に説明します。 ティムの説明を順を追って見ていきましょう。

はじめに：なぜEditorConfigが重要なのか？

TimはまずEditorConfigプロジェクトを紹介し、プロジェクトごとの設定がこれまで以上に簡単に実装できるようになったと説明する。 Visual Studio内に保存された個人的な設定やエディタ設定に依存する代わりに、すべての貢献者のために一貫したコーディングスタイルを維持するようにプロジェクトを構成できるようになりました。

プロジェクトの作成

EditorConfigファイルをデモするために、TimはVisual Studioで新しいBlazor Serverプロジェクトを作成します。 彼はそれをBlazorDemoAppと名付け、デフォルトの設定を使用しています。 このシンプルな.NETプロジェクトは、EditorConfig設定を設定し適用するためのテストベッドとして機能します。

ティムが説明するように、このプロジェクトには複雑なロジックや機能は必要ありません。 これは、コード・スタイル・ルールで作業するための便利な例です。

プロジェクトの好みとコーディングスタイルの理解

ここでは、プロジェクトレベルのコンフィギュレーションがなぜ重要なのかについてTimが説明します。 Visual Studioでは、各ユーザーが次のような設定を行うことができます：

• タブとスペースのどちらを使うか

• インデントサイズ（例：3または4スペース）

• 中括弧{}の同一行または改行への配置

• 名前空間宣言のタイプ（ブロック・スコープまたはファイル・スコープ）

これらの環境設定は、通常、プロジェクトごとではなく、Visual Studioのユーザーごとに保存されます。 ティムは、チームで作業する場合、全員のローカル設定が異なる可能性があることを強調しました。 その結果、コードの書式に一貫性がなくなったり、バージョン管理システムで不要な差分が発生したり、手作業で環境設定を調整する時間が無駄になったりする可能性があります。

EditorConfigファイルフォーマットは、すべての開発者のエディターが自動的に尊重できるEditorConfigプロパティの共有セットを定義します。

EditorConfigファイルの作成とオープン

次にTimは、ソリューションに新しいEditorConfigファイルを追加する方法を示します。

ソリューション上で右クリックし、Add → New EditorConfigを選択します。Visual Studioはファイルを最初に読み込むときに小さなエラーを投げるかもしれませんが、ティムはこれは害のない癖だと説明します。

この新しいファイルは通常.editorconfigという名前で、Visual Studioはすぐにこれを設定ドキュメントとして認識します。 Visual Studioは、Visual Studio CodeやSublime Textのような他のテキストエディタと同様に、テキストエディタプラグインを通して、このファイルをネイティブサポートしていることは注目に値します。

ティムは、EditorConfigがマイクロソフト専用のツールではないことを明らかにしています。 これは、異なるエディタが同じコーディング規約を理解し、適用できるようにするための業界標準であり、複数の環境で一貫した書式を保証します。

コンフィギュレーション エディターコンフィギュレーション ファイルの設定

EditorConfigファイルを開くと、現在のVisual Studioの設定からデフォルトの設定が取り込まれるとTim氏は説明する。 ただし、これらは必要に応じて変更することができます。

彼はホワイトスペースのセクションに移動し、設定方法を示します：

• スペースの代わりにタブを使用

• タブ幅 = 3

これらは、コードの書式設定の動作を定義するEditorConfigプロパティの例です。 一度保存すると、この設定はソリューション全体に適用されますが、ソリューションの外部には適用されません。

Tim氏は、このEditorConfigファイルはバージョン管理システム（Gitなど）にも追加することができ、リポジトリをクローンするすべての開発者が同じルールを継承できるようにすることができると述べている。 これは、誰がコードを書くかに関係なく、一貫した書式を維持するのに役立ちます。

コード スタイルと名前空間ルールを使用する

ティムは次に、コードスタイルの設定、特に名前空間宣言のスタイルについて説明します。

デフォルトでは、C#はブロックスコープの名前空間を使用し、名前空間は中かっこで定義されます。 Tim は Data フォルダの下にクラスを作成し、この形式を示します。

次に、EditorConfigファイルの設定を変更して、ファイルスコープの名前空間を使用するようにします。 彼が別のクラスを追加すると、Visual Studioは自動的に更新されたスタイルを適用し、中括弧の代わりにセミコロン（;）で名前空間を表示します。

これは、EditorConfigの設定がVisual Studioのデフォルトのコード生成テンプレートにどのように影響し、定義されたプロジェクトの規約に自動的に合わせることができるかを示しています。

Timはまた、コードクリーンアップ機能を使用して既存のファイルを再フォーマットし、すべてのコードが最新のEditorConfigルールに準拠していることを確認できることも指摘しています。

深刻度の設定とルールの適用

このセクションでTimは、EditorConfigファイルの重大度レベルを使用してルールの強制を制御する方法に焦点を当てます。

各ルールには、なし、提案、警告、エラーなどの値を指定できます。 Timは名前空間ルールの重要度をエラーに設定し、すぐにVisual Studioはエラー一覧ウィンドウで優先フォーマットに一致しないファイルにフラグを付けます。

これにより、開発者が定義されたスタイルに従うことを保証し、現在のファイルまたはプロジェクト全体における不要な逸脱を防ぎます。

矛盾やVisual Studioのバグ（間違った提案プロンプトなど）が現れるかもしれませんが、Tim氏は、これらは時間の経過とともに改善されると指摘しています。重要なのは、ルールが一貫して適用され、コードが読みやすく統一されていることです。

複数の EditorConfig ファイルとディレクトリのスコープ

Timは、1つのソリューションで複数のEditorConfigファイルを持つことができると説明しています。

例えば：

• ソリューションレベルのルートEditorConfigファイルは、すべてのプロジェクトの一般的な設定を定義します。

• DataのようなサブフォルダーにネストされたEditorConfigファイルは、いくつかのプロパティ（命名規則、タブ幅、改行など）を上書きすることができます。

各EditorConfigプロジェクトは階層的に動作します。つまり、明示的にオーバーライドされない限り、サブディレクトリのファイルは親ディレクトリを継承します。

コンフィギュレーションのルートを定義したい場合は、トップレベルファイルに root = true というプロパティを設定します。これにより、エディターが親ディレクトリを検索してEditorConfigファイルを探すのをやめるようになります。

この構成により、開発者はプロジェクトレベルの書式ルールを細かく制御することができ、また、異なる書式が意味を持つような特殊なケースも許容されます。

結論：EditorConfig による一貫性

最後に、ティムは、開発者が.NETプロジェクトでEditorConfigを積極的に使用することを奨励します。

彼は、このアプローチによって、チームが一貫した書式規則、命名規則、レイアウトスタイルを維持できることを強調しています。 開かれた各ファイルは、プロジェクトの.editorconfigファイルで設定された定義されたスタイルに自動的に従います。

これらのEditorConfigファイルをバージョン管理システムにコミットすることで、チームは、エディタや環境に関係なく、誰もが同じコード書式ルールを遵守することを保証します。

ティムはビデオの最後に、EditorConfigファイル形式がシンプルで柔軟性があり、広くサポートされていることを強調しています。 Visual Studio、Visual Studio Code、または他のテキストエディタのいずれを使用していても、一貫したコーディングスタイルを維持し、プロジェクトをクリーンでプロフェッショナルで読みやすいものに保つのに役立ちます。