Riderのコーディング規約をチーム内で共有する方法

# はじめに
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の初期設定 | ? | しない |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/320192/5eb63412-e57c-af06-8035-c59e1167ef64.png)

https://pleiades.io/help/rider/Sharing_Configuration_Options.html

## EditorConfig
EditorConfigは、様々なエディターで共通して使えるフォーマッターの設定を記述するためのファイルです。
`.editorconfig`というファイルにINIベースで設定を記述します。
ただし、標準のEditorConfigで使用可能なスタイルは少ないため、実用レベルな設定をしたい場合はエディターごとのカスタムスタイルも併用する必要があります。

https://editorconfig.org/

### EditorConfigの出力方法
現在のRiderのフォーマッターの設定をEditorConfigに出力する方法は次の通りです。
1. Code Styleを開く（`File | Settings | Editor | Code Style`）
![](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/320192/867cbe2e-c3fa-4f08-ef2b-a346313aec1a.png)
2. EditorConfigをエクスポートする（`Export`ボタン）
3. エクスポート設定を適宜変更する
    主な設定項目
    * `Section (file mask)`
    どのファイルに適用するか（例 : `Dir/**.cs`）
    * `Export settings that have default values`
デフォルト値のある設定をエクスポートするか
これを有効にすると、各ユーザーのDotSettingsの設定内容にかかわらず、必ず全ての設定が同じになることを保証できます。
数千項目の設定がエクスポートされるため、メンテナンスが大変になるかもしれません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/320192/b322464c-6a54-a614-f0b6-b704329b1408.png)

https://pleiades.io/help/rider/Using_EditorConfig.html#export-code-style-settings

### EditorConfigの有効範囲
`.gitignore`と同じように、対象のファイルに最も近い親ディレクトリにある`.editorconfig`が有効になります。
また、ワイルドカードや`root = true`を使うことで有効範囲を制限することができます。

https://editorconfig.org/#file-location

**EditorConfigは全ての設定レイヤーよりも優先されます**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/320192/a3bb0eb2-a37d-b819-fec8-108a14590044.png)

## 使い分け
ソリューション単位でフォーマッターの設定を共有する場合は、DotSettingsを使うのが良いと思いますが、EditorConfigの方が何かと扱いやすい印象でした。

**DotSettings**
（あまりメリットが見つけられなかったので、他にもメリットがあれば教えてください。）
* メリット
    * ソリューション単位でフォーマッターの設定を共有できる
* デメリット
    * 複数のソリューションを持つプロジェクトで、個々のソリューションにDotSettingsを置くのは面倒
    * Unityでパッケージをサブモジュールとして管理する場合に、サブモジュール側にDotSettingsを置いても反映されない
    個人的にこれが一番大きな問題でした。
    `<GitRoot>/Packages/<PackageName(Submodule)>`のような構成の場合、DotSettingsは`<GitRoot>/<PackageName>.sln.DotSettings`に置かないと反映されないため、サブモジュール側に置くことができません。

**EditorConfig**
* メリット
    * DotSettingsのデメリットを解消できる
* デメリット
    * 特に無し？

# 整形タイミング
Riderでは以下のようなタイミングでフォーマッターを実行することができます。
* `;`を入力したとき
* ファイルを保存したとき
* コードクリーンアップを実行したとき
* コミットする前

https://pleiades.io/help/rider/Enforcing_Code_Formatting_Rules.html

また、CLIのツールを使用してCIでフォーマッターを実行することもできます。

https://pleiades.io/help/rider/CleanupCode.html