コードにおいは、潜在的にバグの数を増やす可能性のあるデザインに問題があることを示す症状です。これはリージョンの場合ではありませんが、リージョンは長いメソッドのようにコードの匂いの作成に寄与する可能性があります。
以来：
アンチパターン（またはアンチパターン）とは、一般的に使用される可能性のあるソーシャルまたはビジネスオペレーションまたはソフトウェアエンジニアリングで使用されるパターンですが、実際には非効率的および/または逆効果です
領域はアンチパターンです。コードの品質や可読性を向上させたり、バグの数を減らしたりすることなく、コードのリファクタリングをより複雑にするだけの、より多くの作業が必要です。
メソッド内で領域を使用しないでください。代わりにリファクタリング
メソッドは短くなければなりません。メソッドに10行しかない場合、他の5行で作業するときに、5行を非表示にするためにリージョンを使用することはおそらくないでしょう。
また、各メソッドは1つだけのことを行う必要があります。一方、リージョンは異なるものを分離することを目的としています。メソッドがAを実行し、次にBを実行する場合、2つの領域を作成することは論理的ですが、これは間違ったアプローチです。代わりに、メソッドを2つの個別のメソッドにリファクタリングする必要があります。
この場合にリージョンを使用すると、リファクタリングがさらに難しくなる可能性があります。あなたが持っていると想像してください：
private void DoSomething()
{
var data = LoadData();
#region Work with database
var verification = VerifySomething();
if (!verification)
{
throw new DataCorruptedException();
}
Do(data);
DoSomethingElse(data);
#endregion
#region Audit
var auditEngine = InitializeAuditEngine();
auditEngine.Submit(data);
#endregion
}
最初の領域を折りたたんで2番目の領域に集中するのは危険であるだけでなく、フローを停止する例外を簡単に忘れることができます（return代わりにガード句があり、それを見つけるのはさらに困難です）。この方法でコードをリファクタリングする必要がある場合：
private void DoSomething()
{
var data = LoadData();
#region Work with database
var verification = VerifySomething();
var info = DoSomethingElse(data);
if (verification)
{
Do(data);
}
#endregion
#region Audit
var auditEngine = InitializeAuditEngine(info);
auditEngine.Submit(
verification ? new AcceptedDataAudit(data) : new CorruptedDataAudit(data));
#endregion
}
現在、リージョンは意味をなさないため、最初のリージョンのコードを見なくても、2番目のリージョンのコードを読んで理解することはできません。
私が時々見る別のケースはこれです：
public void DoSomething(string a, int b)
{
#region Validation of arguments
if (a == null)
{
throw new ArgumentNullException("a");
}
if (b <= 0)
{
throw new ArgumentOutOfScopeException("b", ...);
}
#endregion
#region Do real work
...
#endregion
}
引数の検証が数十のLOCにまたがり始めたときに領域を使用するのは魅力的ですが、この問題を解決するためのより良い方法があります。
public void DoSomething(string a, int b)
{
if (a == null)
{
throw new ArgumentNullException("a");
}
if (b <= 0)
{
throw new ArgumentOutOfScopeException("b", ...);
}
InternalDoSomething(a, b);
}
private void InternalDoSomething(string a, int b)
{
...
}
メソッド以外の領域をグループ化しないでください
一部の人々はそれらを使用してフィールド、プロパティなどをグループ化します。このアプローチは間違っています。コードがStyleCopに準拠している場合、フィールド、プロパティ、プライベートメソッド、コンストラクタなどはすでにグループ化されており、簡単に見つけることができます。そうでない場合は、コードベース全体で均一性を確保するルールを適用することを検討してください。
他の人々は地域を使用して多くの同様の実体を隠します。たとえば、100個のフィールド（コメントと空白を数えると少なくとも500行のコードが作成される）を持つクラスがある場合、それらのフィールドを領域内に配置し、折りたたんで、忘れてしまいがちです。繰り返しますが、あなたはそれを間違っています：クラスに非常に多くのフィールドがあるので、継承を使用するか、オブジェクトをいくつかのオブジェクトにスライスすることを考える必要があります。
最後に、一部の人々は、関連するものをグループ化するために領域を使用するように誘惑されます：デリゲートを伴うイベント、またはIOに関連する他のメソッドを伴うIOに関連するメソッドなど。 、読んで理解する。2番目のケースでは、おそらく複数のクラスを作成する方が適切です。
地域に適した用途はありますか？
いいえ。従来の使用法：生成されたコードがありました。それでも、コード生成ツールは、代わりに部分クラスを使用する必要があります。C＃にリージョンサポートがある場合、これは主にこのレガシー使用であり、コードでリージョンを使用する人が多すぎるため、既存のコードベースを壊さずにそれらを削除することは不可能だからです。
について考えてみてくださいgoto。言語またはIDEが機能をサポートしているという事実は、その機能を毎日使用する必要があるという意味ではありません。StyleCop SA1124ルールは明確です。リージョンを使用しないでください。決して。
例
現在、同僚のコードのコードレビューを行っています。コードベースには多くのリージョンが含まれており、実際には、リージョンを使用しない方法と、リージョンが悪いコードにつながる理由の両方の完璧な例です。ここではいくつかの例を示します。
4000 LOCモンスター：
私は最近、usingPrograms.SEのどこかで、ファイルに含まれるsの数が多すぎる場合（「Unused Usingsを削除」コマンドを実行した後）、このファイル内のクラスが多すぎることを示しています。同じことがファイル自体のサイズにも当てはまります。
コードを確認しているときに、4000 LOCファイルに出会いました。このコードの作成者は、同じ15行のメソッドを何百回もコピーアンドペーストし、変数の名前と呼び出されたメソッドをわずかに変更したように見えました。単純な正規表現では、ジェネリックをいくつか追加するだけで、ファイルを4000 LOCから500 LOCにトリミングできました。より巧妙なリファクタリングにより、このクラスは数十行に削減される可能性があると確信しています。
リージョンを使用することにより、著者は、コードを維持することが不可能であり、記述が不十分であるという事実を無視し、コードをリファクタリングするのではなく複製することを奨励しました。
地域「Do A」、地域「Do B」：
別の優れた例は、単純にタスク1、タスク2、タスク3などを実行するモンスター初期化メソッドです。完全に独立した5〜6つのタスクがあり、それぞれがコンテナクラスの何かを初期化します。これらのタスクはすべて1つのメソッドにグループ化され、リージョンにグループ化されました。
これには1つの利点がありました。
- この方法は、地域名を見ると理解しやすいものでした。これは、リファクタリングされた同じメソッドが元のメソッドと同じくらい明確になると言われています。
一方、問題は複数ありました。
フィールド領域、プロパティ領域、コンストラクター領域：
また、レビューされたコードには、すべてのフィールド、すべてのプロパティなどをグループ化した多くの領域が含まれていました。これには、ソースコードの増加という明らかな問題がありました。
ファイルを開いてフィールドの膨大なリストを見ると、最初にクラスをリファクタリングしてからコードを操作する傾向が強くなります。地域では、物を折りたたんでそれを忘れる習慣があります。
別の問題は、どこでもそれを行うと、1ブロックの領域を作成することに気付くということです。これは意味がありません。これは、実際に私がレビューしたコードの場合で、#region Constructor1つのコンストラクターがたくさん含まれています。
最後に、フィールド、プロパティ、コンストラクターなどはすでに順番に並んでいるはずです。それらが慣例（大文字で始まる定数など）に一致する場合、要素のタイプがどこで停止し、他の要素が始まるかはすでに明らかなので、そのための領域を明示的に作成する必要はありません。