完全に私個人の考えにおいての内容なのであんまり参考にはしてほしくなかったりするのですが、こういうつけ方もあるよー、的なものとして書いておきます。
通常 Region ディレクティブの使い方としては複数のプロパティやメソッドを特定のグループとしてまとめて折りたためるようにしてコード全体を見やすくするために使います。一例としては下のような感じですかね。
#region プロパティ
public int X { get; set; }
public int Y { get; set; }
#endregion
こういう使い方は私も割と普通にします。しかし、特定のグループとして region でまとめあったとして、どのグループにいれるか判断が難しいメソッドを作成した時にどっちの region に入れるべきか迷うことが多々あります。
仮に文字列処理を「変換系」「検索系」の region でまとめたとします。そこに「Dictionary から特定のキーの値を探し出し、テキストを HTML に出力できるように変換し文字列を返す。」というメソッドを作成した場合「変換系」なのか「検索系」なのかかなり迷うことがあります。
まあこれは一例なのでほかにももっとバリエーションがあったりするのですが、そんなこんなで最近はグループのまとめとしての region はあまり使いません。
でも可視化するコードの量は減らしたいので、別案としてよくあるのが「メソッド単位で囲む」になると思います。例としては
#region " ToRadian : Degree から Radian に変換 "
/// <summary>
/// 角度を Degree から Radian に変換します。
/// </summary>
/// <param name="degree">Degree 単位の角度。</param>
/// <returns>Radian 単位の角度。</returns>
public static float ToRadian(float degree)
{
return degree * (float)Math.PI / 180.0f;
}
#endregion
これでメソッドを1行にまとめることができます。しかし、これにはデメリットがあり、折りたたんだ場合にそのメソッドがどんなものなのかを示す情報が region の行1行にしかありません。さらに XML コメントとは別に起こさないといけないので、書くのが2度手間になり、修正も2度手間です。説明や引数が多かった場合でもなんとかして1行に収めないといけないです。
上記のような諸々の事情を解決するため、私は region を下のようにつけるようにしました。
/// <summary>
/// 角度を Degree から Radian に変換します。
/// </summary>
/// <param name="degree">Degree 単位の角度。</param>
/// <returns>Radian 単位の角度。</returns>
public static float ToRadian(float degree)
#region
{
return degree * (float)Math.PI / 180.0f;
}
#endregion
例は1行しかないので全然メリットはないんですが、こうすることによって概要や引数、戻り値の情報が見れる状態でコードを折りたたむことができます。別途 region 用のコメントを書かなくていいのもメリットですね。もちろん1行regionよりは行数が増えてしまいますが、まあ、ここら辺はどうしようもないでしょう。増えすぎたらグループをregionでまとめて(最初に戻る)
ちなみにこの region のまとめ方は正規法でもなんでもないので、VB.NET で同じやり方をすると構文エラーで怒られます。こんなやり方もあるよー程度にしておいてください・・・。
]]>
