c# - StyleCop SA1124 DoNotUseRegionsは妥当ですか？

Question

SA1124 DoNotUseRegionsは、リージョンをどこでも使用しないことを提案しています。本当にリーズナブルですか？

リージョンは、相対コードをグループ化して大きなクラスを読みやすくする方法だと思います。たとえば、コンテキストメニューを使用してvs2008でクラスのインターフェイスメソッドを生成すると、リージョンが自動的に挿入されます。

コードスタイルをチェックしながら、このルールを削除したいと思います。このルールについてのご意見をお聞かせください。

score 19 · Accepted Answer

適切に記述されたコードでは、リージョンはもう必要ありません。かつては、マシンで生成されたコードを非表示にすることが役に立ちました。これで、そのコードは別のファイルに入れられます。リージョンは、不十分に記述されたコードを非表示にするために引き続き使用できます。

score 18 · Accepted Answer

これは個人的な好みになります。ここで重要なのは、あなたとあなたのチームが好むものだけです。StyleCopの言うことを忘れてください。あなたがそれを読んでいるのです。あなたはそれを維持しているのです。リージョンの有無にかかわらず、それが重要です。

あなたがそれをオープンソースプロジェクトとしてリリースしているなら...そしてこれはここでの私の意見です、私は同じことが当てはまると思います。コアチームがより快適なものを使用してください。より多くのチームメンバーを参加させ、より多くの貢献をした場合は、後で問題を再検討してください。これはいつでも変更できます。

score 7 · Accepted Answer

リージョンは悪用される可能性があると思いますが、リーダーがコードの特定の領域に一度に集中できるようにするための便利なテクニックです。

ただし、ネストのレベルが多すぎることは避けます。

score 7 · Accepted Answer

私はリージョンと私のチームが好きで、コードはリージョンで読みやすくなっていると感じています。

これが私が彼らを愛する時です...

Arrange Act Assert（AAA）を使用して単体テストを作成するための会社標準がある場合は、次のように単体テストを要求できます。

[test]
public void MyFunction_Test
{
#region Arrange
#endregion    

#region Act
#endregion

#region Assert
#endregion
}

私はこのフォーマットが本当に好きです。特に明確な分離があり、そうすることで他の人がユニットテストを正しく書くなど、何かを正しく行うように促します。

私がリージョンが好きなもう1つの場所は、コードをすぐに削除することがわかっている場合です。

#region Drop this region next version when we drop 2003 support
public void DoSomeThingWithWindowsServer2003()
{
   // code the is for Windows 2003 only
} 
#endregion

また、クラスが非常に小さい場合でも、リージョンを使用してクラスのさまざまな部分を分離します。

#region Constructors
#endregion

#region Properties
#endregion

#region Events
#endregion

#region Methods
#endregion

#region Enums
#endregion

通常、クラスにはこれらすべてが含まれているわけではありませんが（1つのクラスで多くのことを行っているかどうか疑問に思うかもしれません）、単一のメソッドまたはプロパティを探している場合は、単一の場所があると便利だと思います。見てください。INotifyPropertyChangedを使用するViewModel（MVVMは誰ですか？）のプロパティは10行（9行とスペース）であるため、5つのプロパティのみを持つ適切に設計および記述されたViewModelオブジェクトは、プロパティセクションが少なくとも50行であることを意味しますコードの。

私はまた、他の誰かの不十分に書かれたコードを使用するときにそれらが特に好きです。完璧なデザインを使用するためにいつでもリファクタリングできると考えるのはばかげています。たとえば、2500行以上のクラスがあるとします。確かにこれはもっとうまく書かれている可能性がありますが、あなたはそれをしませんでした、それは動作します、そしてそれはテストされ、あなたのビジネスは「修正のみ」のロックダウンのコードを持っているのでリファクタリングは許可されません。#regionステートメントを使用して、非常に大きなクラス（記述が不十分かどうかに関係なく）をはるかに読みやすくすることができます。クラスを実際に分離せずに関心の分離の可読性の利点をたくさん得ることができ、コードがロックダウンから抜け出してリファクタリングできるようになると、分離作業の大部分はすでに#regionsを使用して行われている可能性があり、リージョンを別のクラスに分けます。

score 4 · Accepted Answer

私の意見では、＃region /＃endregionが理にかなっている例外が1つあります。それは、インターフェイスを実装する場合です。

例えば

#region Implementation of IDisposable
public void Dispose()
{
  // implementation here ...
}
#endregion

他のすべての場合は、廃止されているため#regionを使用しないでください（生成されたコードを非表示にするために作成された場所-.net-1.0および.net-1.1を想定していますが、現在はそのための部分的なクラスがあります）

score 4 · Accepted Answer

私の経験から、それらはまったく使用されるべきではありません。ジュニア開発者はそれらを悪用し、非常に複雑なクラスを作成する傾向があり、その複雑さは多くの地域の背後に「スマートに」隠されています。

score 2 · Accepted Answer

このルールは、プライベート/保護/パブリックメンバーの順序など、他のより一般的に受け入れられているルールの副作用ではないかと思います。これらの順序付け規則に従うと、多くの場合、必然的に#regionsの論理的なグループ化が破られるため、相互に排他的になります。

c# - StyleCop SA1124 DoNotUseRegionsは妥当ですか？

7 に答える 7

Related

Reference