はじめに
Rider（ReSharper）のフォーマッターの設定をチーム内で共有する方法について調べてみました。
使用したRiderのバージョンはRider 2023.3.1です。
目的
- コーディング規約に関するドキュメント作成やPRのレビューの負荷を減らす
- DotSettingsだけでは対応できないケースへの対応
Unityのパケージをサブモジュールとして追加して運用するようなケース
扱うもの
- Riderのフォーマッター（
File | Settings | Editor | Code Style）
扱わないもの
- Riderのリンター（
File | Settings | Editor | Inspection Settings） - Roslyn Analyzer（StyleCopやRoslynator）
フォーマッターの設定の共有方法
設定の共有方法は主にDotSettingsとEditorConfigの2つがあります。
詳しくは#使い分けに書きましたが、EditorConfigの方が何かと扱いやすい印象でした。
DotSettings
多くのRiderの設定は、DotSettingsというファイルに保存されています。
フォーマッターの設定もこれに含まれており、ソリューションのDotSettingsをGit等のVCSで共有することで、同じ設定を使うことができます。
設定レイヤー
Riderの設定にはレイヤーという概念があります。
レイヤー構成は次のようになっていて、上のレイヤーの設定が下のレイヤーの設定を上書きします。
| レイヤー（降順） | 概要 | パス | VCSでの共有 |
|---|---|---|---|
| Solution personal | ソリューションの設定（個人） | <SolutionDir>/.<SolutionName>.sln.DotSettings.user |
しない |
| Solution team-shared | ソリューションの設定（チーム） | <SolutionDir>/.<SolutionName>.sln.DotSettings |
する |
| This computer | PC内（ユーザー）の設定 | %APPDATA%/JetBrains/Rider2023.3/resharper-host/GlobalSettingsStorage.DotSettings |
しない |
| Default settings | Riderの初期設定 | ? | しない |
EditorConfig
EditorConfigは、様々なエディターで共通して使えるフォーマッターの設定を記述するためのファイルです。
.editorconfigというファイルにINIベースで設定を記述します。
ただし、標準のEditorConfigで使用可能なスタイルは少ないため、実用レベルな設定をしたい場合はエディターごとのカスタムスタイルも併用する必要があります。
EditorConfigの出力方法
現在のRiderのフォーマッターの設定をEditorConfigに出力する方法は次の通りです。
- Code Styleを開く（
File | Settings | Editor | Code Style）
- EditorConfigをエクスポートする（
Exportボタン） - エクスポート設定を適宜変更する
主な設定項目-
Section (file mask)
どのファイルに適用するか（例 :Dir/**.cs） -
Export settings that have default values
デフォルト値のある設定をエクスポートするか
これを有効にすると、各ユーザーのDotSettingsの設定内容にかかわらず、必ず全ての設定が同じになることを保証できます。
数千項目の設定がエクスポートされるため、メンテナンスが大変になるかもしれません。
-
EditorConfigの有効範囲
.gitignoreと同じように、対象のファイルに最も近い親ディレクトリにある.editorconfigが有効になります。
また、ワイルドカードやroot = trueを使うことで有効範囲を制限することができます。
EditorConfigは全ての設定レイヤーよりも優先されます
使い分け
ソリューション単位でフォーマッターの設定を共有する場合は、DotSettingsを使うのが良いと思いますが、EditorConfigの方が何かと扱いやすい印象でした。
DotSettings
（あまりメリットが見つけられなかったので、他にもメリットがあれば教えてください。）
- メリット
- ソリューション単位でフォーマッターの設定を共有できる
- デメリット
- 複数のソリューションを持つプロジェクトで、個々のソリューションにDotSettingsを置くのは面倒
- Unityでパッケージをサブモジュールとして管理する場合に、サブモジュール側にDotSettingsを置いても反映されない
個人的にこれが一番大きな問題でした。
<GitRoot>/Packages/<PackageName(Submodule)>のような構成の場合、DotSettingsは<GitRoot>/<PackageName>.sln.DotSettingsに置かないと反映されないため、サブモジュール側に置くことができません。
EditorConfig
- メリット
- DotSettingsのデメリットを解消できる
- デメリット
- 特に無し？
整形タイミング
Riderでは以下のようなタイミングでフォーマッターを実行することができます。
-
;を入力したとき - ファイルを保存したとき
- コードクリーンアップを実行したとき
- コミットする前
また、CLIのツールを使用してCIでフォーマッターを実行することもできます。