.net - #region ディレクティブは .NET で本当に役に立ちますか?

Question

(C# と VB.NET の両方で) #region が散らばる多くのコードを維持した後、この構造はプログラマーにとって単なる「作業」の束にすぎないように思えます。やっかいなことをコードに入れるのは仕事であり、コードを検索して読むのは非常に面倒です。

利点は何ですか？なぜコーダーはこれを自分のコードに入れるのに余計な苦労をするのでしょうか。

私を信者にしてください！

score 22 · Accepted Answer

同様の質問がすでに出されています。

しかし...

私はもうないと言うでしょう。もともとは、初期バージョンの .NET で生成されたコードを WinForms から隠すことを目的としていました。部分クラスを使用すると、必要がなくなるようです。私見では、組織の構造として過剰に使用されており、コンパイラの価値はまったくありません。それはすべてIDEのためです。

score 17 · Accepted Answer

多くの場合、パーシャルと #regions の両方が悪い設計の松葉杖として使用されます (たとえば、クラスが大きすぎる、またはあまりにも多くのことをしようとします)。

#regions のこれまでの最良の使用法は、多くの異なるクラスで見られる機能のグループ化です。たとえば、getter、setter、コンストラクタ、およびサポートフィールドを持つ値オブジェクトです。それらのアイデアを地域にグループ化することは非常にうまくいくかもしれません。ただし、それによってコードがきれいになるか、読みにくくなるかについては、意見の問題です。

score 14 · Accepted Answer

http://www.rauchy.net/regionerate/ - コードを自動的に地域化します;)

私は、大規模なクラスのセクションをグループ化するための領域のファンです。たとえば、すべてのプロパティをまとめたり、すべてのコンスタンスなどを言います。私は、その時点で見る必要のないコードを常に折りたたんでいる人なので、そのための領域が大好きです。

また、インターフェイス、特に複数のインターフェイスを実装する場合、リージョンは非常に便利です。各インターフェイスのメソッド、プロパティ、イベントなどをグループ化できるので、どのメソッドがどのインターフェイスに属しているかを一目で簡単に確認できます。

score 6 · Accepted Answer

いつも使っています。繰り返しになりますが、他のものと同様に、それらは悪と善の両方に使用でき、確かに悪い設計の特徴となる可能性がありますが、コードを非常にうまく整理するために使用できます。

#region Properties

#region Update Section

#region Accessors

確かにあなたはジェフの例を避けるべきです

#Sweep under carpet

ジェフが指摘したように、私がそれらについて奇妙だと思うのは、それらがuiの目的のためのコンパイラプリプロセッサコマンドであるということです。VSチームは別の方法で同じように役立つことをしたかもしれないと確信しています。

score 4 · Accepted Answer

私たちのビジネスオブジェクトにはすべてリージョンがあり、私たちはそれらを愛しています。

我々は持っています;

ビジネスのプロパティと方法
共有メソッド
コンストラクター
承認
データアクセス
イベント

扱っているビジネスオブジェクトのタイプ（サブスクライバーなど）に応じて、他にもいくつかあります。

多くのクラスでは、リージョンが邪魔になりますが、標準のビジネスオブジェクトの場合は、時間を大幅に節約できます。これらのビジネスオブジェクトはコード生成されているため、非常に一貫性があります。散らかっていない場合は、散らかっているよりもずっと速くなりたい場所にたどり着くことができ、一貫性があるため、お互いのものを簡単に見つけることができます。

score 3 · Accepted Answer

依存関係プロパティという特定のケースを除いて、通常はコード領域を使用しません。依存関係プロパティは、ほとんどの点で楽しく作業できますが、その宣言は目障りで、すぐにコードが乱雑になります。(まるで GUI コードを管理するだけでは十分ではないかのように...)

リージョンには、CLR プロパティ宣言とまったく同じ名前を付けるのが好きです (コピーしてそこに貼り付けます)。そうすれば、折りたたまれたときにスコープ、タイプ、および名前を確認できます。これは、95% の時間で本当に気にかけていることのすべてです。

   #region public int ObjectDepthThreshold

    public int ObjectDepthThreshold
    {
        get { return (int)GetValue(ObjectDepthThresholdProperty); }
        set { SetValue(ObjectDepthThresholdProperty, value); }
    }

    public static readonly DependencyProperty ObjectDepthThresholdProperty = DependencyProperty.Register(
        &quot;ObjectDepthThreshold&quot;,
        typeof(int),
        typeof(GotoXControls),
        new FrameworkPropertyMetadata((int)GotoXServiceState.OBJECT_DEPTH_THRESHOLD_DEFAULT,
            FrameworkPropertyMetadataOptions.AffectsRender,
            new PropertyChangedCallback(OnControlValueChanged)
        )
    );

    #endregion

それが崩壊したとき、あなたはただ見るだけです

public int ObjectDepthThreshold

複数の依存関係プロパティがある場合は、次の #region を次の行から開始するのが好きです。そうすれば、それらすべてがクラスにまとめられ、コードはコンパクトで読みやすくなります。

ところで、宣言をのぞき見したいだけの場合は、マウスをその上に置きます。

score 2 · Accepted Answer

最も単純な使用法を除いて、コードが難読化されていることがわかりました。私たちがプロジェクトで提唱している唯一の用途は、IDEが使用する用途（インターフェースの実装とデザイナーコード）です。

適切なツールを適切な目的に使用する必要があります。コードは、物事を恣意的にグループ化するのではなく、意図と機能を示すように作成する必要があります。アクセス修飾子のグループ化やその他のグループ化に物事を整理することは、非論理的であるように思われます。コードは、特定のクラスにとって意味のある方法で編成する必要があると思います。結局のところ、アクセス修飾子でクラスメンバーを表示するための他のツールがあります。これは、他のほとんどすべてのリージョンの使用にも当てはまります。より良い方法があります。

たとえば、プロパティ、イベント、定数などをグループ化しても、実際には意味がありません。関数ごとにグループ化すると、コードの保守性が向上するためです（たとえば、定数を使用するプロパティは、その定数に近い必要があります。プロパティであるという理由だけで、他の無関係なプロパティの近くにあります）。

score 2 · Accepted Answer

これらの使いすぎは嫌いです。私が便利だと思う唯一のことは、おそらく二度と見たくないものを隠すことです. 繰り返しになりますが、それらはおそらくどこかの図書館にあるはずです。

score 2 · Accepted Answer

Russell Myers が以前に言ったことを続けると、コードを適切にリファクタリングする方法 (熟練した開発者が習得する必要があるスキル) を学べば、実際にはリージョンはあまり必要ありません。

数週間前、リージョンは太いコードを隠すことができるので素晴らしいと思っていましたが、コードスキルを試した結果、よりスリムにすることができ、今ではサイズ 7 クラスに収まるようになりました (誰かがそれを測定する必要があります)。将来のリファクタリングのために! :P)

score 2 · Accepted Answer

特に Web 開発では、メソッドが長くなければならない場合があります。そのような場合 (大規模で複雑なオブジェクトがバインドされたグリッドビューを取得した場合など)、領域を使用すると便利であることがわかりました。

#region Declaring variables for fields and object properties

#region Getting the fields in scope

#region Getting the properties of the object

#region Setting Fields

これらは分割できるメソッドの個別のセクションですが、難しいでしょう (私が望むよりも大きなスコープの変数を使用するか、多くの変数を 'out' として渡す必要があります)、それは基本的な配管です。

この場合、リージョンは完全に受け入れられます。他の人では、それらは不要です。

また、リージョンを使用してメソッドを論理グループにグループ化します。デバッグ中に多くのページを開いている傾向があり、オブジェクト (またはページ、またはダイアログ) 内の部分クラスが少ないほど、より多くの部分クラスを使用できるため、この目的で部分クラスを拒否します。私のタブリスト（より多くのコードを見ることができるように1行に制限しています）.

領域が問題になるのは、松葉杖として使用する場合、または貧弱なコードをカバーする場合のみです (たとえば、同じスコープ内で領域を相互にネストしている場合、これは悪い兆候です)。

score 2 · Accepted Answer

クラスの本体で機能のグループを順序付けるために、コメントの代わりにそれらをよく使用します。たとえば、「構成パブリックインターフェイス」、「ステータスパブリックインターフェイス」、「内部処理」、「内部ワーカースレッド管理」などです。

「定義に折りたたむ」および「現在のブロックを展開する」ためのキーボードショートカットを使用すると、より大きなクラスでも簡単にナビゲートできます。

残念ながら、リージョンは C++ では壊れており、MS は修正する必要はないと考えています。

score 1 · Accepted Answer

これらは多用される可能性がありますが、プライベートメソッド、パブリックメソッド、プロパティ、およびインスタンス変数を分離するのに適しています。

score 1 · Accepted Answer

地域が好きなのは、自分が取り組んでいることだけに集中できるからです。クラスにメソッドしかない場合でも、それらを使用します。

コードスニペットには、領域が事前に入力されているため、入力が少なくて済みます。クラスはより組織化されており、Code Complete で説明されていることは、他の人が読みやすくなっていると感じています。コンパイラはそれらを無視するだけで、コードを読みやすくするためのものです。

score 1 · Accepted Answer

他の言語機能と同様に、地域は誤用や悪用される可能性がありますが、利点もあります。

これらは、次のような「折りたたみ」グループを作成するのに最適です。

メソッド、特にオーバーロードされたメソッドがたくさんある場合
インターフェースの実装
演算子のオーバーロード

プロパティ、パブリック/プライベートメソッド、イベント、クラス全体の変数などをグループ化するためにも使用できます。

コード内で領域を使用して、コード内で一貫した構造を作成できるようにしています。はい、リファクタリング中や新しい機能の追加中 (特に Visual Studio によって自動生成された場合) は少し難しくなりますが、物事の一貫性と構造を維持するために支払う代償は小さいと思います。

score 1 · Accepted Answer

良い答えです。悪いコーディングや設計を反映している場合があるという意見に同意しますが、SandCastle でドキュメント (MSDN スタイル) を作成している場合は #region が実際に役立ちます。パブリック API があり、使用例を示したい基本クラスがあるとします。次に、パブリックメソッドを適切に文書化し、いくつかのコードをコピーアンドペーストできるサンプル領域を追加します。これの問題は、基本クラスが変更された場合、最終的に例を変更する必要があることです。より良い解決策は、サンプルコードプロジェクトをソリューションに含め、それをまとめてビルドすることです。そのため、サンプルコードが最新でない場合、ソリューションをビルドするたびにコンパイルされません。それで、それはあなたが今までにあなた自身に尋ねている地域と何の関係があるのでしょうか. このサンプルをよく見てください：

/// <example>
    /// The following code sample is an implementation of LoadPublishedVersion() for XmlPageProvider.
    /// <code source="../CodeSamples/EPiServerNET/PageProvider/XmlPageProvider.cs" region="LoadPublishedVersion" lang="cs"/>
    /// </example>

ドキュメントでサンプルとして公開するメソッドのソースコードサンプルファイルとリージョンへのリンクがあることに注意してください。ここで結果を参照してください。そのメソッドは適切なリージョンにある必要があり、ドキュメントに自動的に含まれます。だから私はまだ #region を捨てません。

score 0 · Accepted Answer

本当にメリットがありません。それらはコードの匂いです。しばらく使った後、私はそれらにうんざりしました。機能別に分割する必要がある場合は、部分クラスを使用します。

score -1 · Accepted Answer

私の勤務日は、エディターでファイルを開き、[すべて展開] をクリックしてすべてのリージョンを非表示にすることから始まります。その後、私は仕事を始めることができます。

.net - #region ディレクティブは .NET で本当に役に立ちますか?

17 に答える 17

Related

Reference