Visual Studio 環境の皆さんは、#regions でコードをラップすることについてどう思いますか? (または、他のIDEに似たものがあれば...)
24 に答える
10回のうち9回、コードフォールディングは、SoCの原則をその価値のために使用できなかったことを意味します。
私は多かれ少なかれ部分的なクラスについて同じことを感じます。大きすぎると思われるコードがある場合は、非表示にしたり分割したりするのではなく、管理しやすい(そして再利用可能な)部分に分割する必要があります。
次回誰かがそれを変更する必要があるときにそれはあなたを噛み、メソッドの250行のモンスターに隠されたロジックを見ることができません。
可能な場合はいつでも、メインクラスからヘルパークラスまたはファクトリクラスにコードをプルします。
foreach (var item in Items)
{
//.. 100 lines of validation and data logic..
}
読みにくい
foreach (var item in Items)
{
if (ValidatorClass.Validate(item))
RepositoryClass.Update(item);
}
とにかく私の$0.02。
これはCoding Horrorで話題になりました。
私の個人的な信念は、それらは有用であるということです。
これを使用して、コード ブロックを次のように並べ替えます。
列挙型
宣言
コンストラクター
メソッド
イベント ハンドラー
プロパティ
#regions が奨励されている、または必要とされているチームで作業していることに気付く場合があります。あなたが私のようで、折りたたまれたコードをいじるのに耐えられない場合は、C# のアウトラインをオフにすることができます。
- オプション -> テキスト エディター -> C# -> 詳細設定タブ
- 「ファイルを開くときにアウトラインモードに入る」のチェックを外す
#Region を使用して、部分クラスの自動生成された部分に実際に属している、醜くて役に立たない自動生成されたコードを非表示にします。しかし、古いプロジェクトやアップグレードされたプロジェクトで作業する場合、常にその余裕があるとは限りません。
他の種類の折りたたみに関しては、私は常に関数を折りたたんでいます。関数に適切な名前を付ければ、何かをテストしたり (再) 作成したりしない限り、内部を見る必要はありません。
ジェフらの問題は理解していますが。アル。私が理解していないCTRLのは、 + M、CTRL+Lを押してファイル内のすべてのリージョンを展開するのが非常に難しい理由です。
コードの折りたたみ機能を備えたTextmate (Mac のみ) を使用していますが、折りたたみ機能に非常に便利です。「getGet」関数が何をするかを知っています。貴重な画面スペースを 10 行占有する必要はありません。
同じコードを 2 回表示することを避けるために、他の人にコードを表示しない限り、for ループや if ステートメントなどを非表示にするために使用することはありません。
私はリージョンよりも部分クラスを好みます。
他の人がリージョンを広範囲に使用していると、どこかで誰かが単一責任の原則に違反しており、1 つのオブジェクトで多くのことをしようとしているような印象を受けます。
@トム
部分的なクラスが提供されているため、ツールで自動生成されたコードを、コード生成が少し完了した後に行う必要があるカスタマイズから分離できます。これは、codegen を再実行した後もコードがそのまま残り、上書きされないことを意味します。これは良いことです。
一般に、C# のイベントのようなコードを扱う場合、実際にはイベント宣言 (EventArgs クラス、デリゲート宣言、およびイベント宣言) の一部にすぎない約 10 行のコードがあることがわかります。途中で、もう少し読みやすくなります。
これは、どこにも通じないばかげた議論の 1 つにすぎません。地域が好きなら、それらを使用してください。そうでない場合は、エディターを構成してオフにします。そこに、誰もが幸せです。
メソッド内で領域を使用してはなりません。これらはメソッドをグループ化するために使用できますが、コードの読者が気が狂わないように細心の注意を払って処理する必要があります。修飾子によってメソッドを折りたたむことに意味はありません。ただし、折り畳むと可読性が向上する場合があります。たとえば、外部ライブラリを使用するときにいくつかの問題を回避するために使用するいくつかのメソッドをグループ化し、あまり頻繁にアクセスしたくない場合に役立つ場合があります。ただし、コーダーは、この特定の例でライブラリを適切なクラスでラップするなどの解決策を常に模索する必要があります。他のすべてが失敗した場合は、読みやすさを向上させるために折りたたみを使用してください。
私は部分クラスのファンではありません。各クラスが責任を負う非常に明確な単一の問題を持つようにクラスを開発しようとしています。そのためには、明確な責任を持つものを複数のファイルに分割する必要があるとは思いません。そのため、部分クラスは好きではありません。
そうは言っても、私は地域についてのフェンスにいます。ほとんどの場合、私はそれらを使用しません。ただし、私は毎日、リージョンを含むコードを扱っています。一部の人は非常に重くします (プライベート メソッドをリージョンに折りたたんでから、各メソッドを独自のリージョンに折りたたむ)。属性を折りたたむなど)。現時点での私の一般的な経験則は、(a) データが静的なままである可能性が高いか、(enum のように) あまり頻繁に触れられない場合、または (b) 以下のメソッドがある場合にのみ、リージョンにコードを配置することです。サブクラス化または抽象メソッドの実装のために必要に応じて実装されますが、繰り返しになりますが、あまり頻繁には触れられません。
言語に固有のコードの機能に基づいて領域のグループ化を手動で維持する必要がなければ、領域の折りたたみは問題ありません。たとえば、コンパイラはそれがコンストラクタであることを既に認識しています。IDE のコード モデルは、それがコンストラクタであることを既に認識しています。しかし、コンストラクターがグループ化されているコードのビューを見たい場合は、何らかの理由で、これらがコンストラクターであるという事実を、物理的に一緒に配置し、それらの周りにグループを置くことによって、もう一度述べなければなりません。同じことが、クラス/構造体/インターフェースをスライスする他の方法にも当てはまります。気が変わって、公開/保護/非公開を最初にグループに分けてから、メンバーの種類ごとにグループ化して表示したい場合はどうすればよいですか?
領域を使用してパブリック プロパティをマークすることは (たとえば)、コード自体から既に識別できるものに何も追加しない冗長なコメントを入力するのと同じくらい悪いことです。
とにかく、その目的で領域を使用する必要がないように、Ora という無料のオープン ソース Visual Studio 2008 IDE アドインを作成しました。グループ化されたビューが自動的に提供されるため、物理的なグループ化を維持したり、領域を使用したりする必要がはるかに少なくなります。役に立つかもしれません。
うまく使えば便利なツールだと思います。多くの場合、メソッドや列挙など、折りたたまれていることが多いものは、小さなブラック ボックスにする必要があると思います。何らかの理由でそれらを見る必要がない限り、それらの内容は重要ではなく、可能な限り非表示にする必要があります。ただし、プライベート メソッド、コメント、または内部クラスを折りたたむことはありません。メソッドと列挙型は、実際に折りたたむ唯一のものです。
私は個人的に #Regions を常に使用しています。プロパティや宣言などを互いに分離しておくと役立つことがわかりました。
これもおそらく良い答えです!
編集:ダン、パットはこれに私を打ち負かしました!
私のアプローチは、領域を使用してコード ブロックをコンストラクター、プロパティ、イベントなどに編成する他のいくつかのアプローチと似ています。
Roland Weigelt による VS.NET マクロの優れたセットが、彼のブログ エントリ、Better Keyboard Support for #region ... #endregionから入手できます。私はこれらを何年も使用しており、ctrl + をマッピングしています。現在の領域を折りたたむには ctrl++ を押して展開します。すべてを折りたたみ/展開するデフォルトのVS.NET機能よりもはるかにうまく機能することがわかります。
Eclipseは、これの一部をJava(またはプラグインを使用するPHP)で独自に実行します。関数などを折りたたむことができます。私はそれが好きになる傾向があります。関数が何をするのかを知っていて、それに取り組んでいない場合は、それを見る必要はありません。
列挙
プロパティ
.ctors
メソッド
イベント ハンドラ
リージョンを使用するのはこれだけです。メソッド内でそれらを使用できるとは思いもしませんでした。
ひどいアイデアのように聞こえます:)
Coding Horrorの記事では、これについても考えさせられました。
一般に、大きなクラスでは、メンバー変数、定数、およびプロパティの周りにリージョンを配置して、スクロールしなければならないテキストの量を減らし、他のすべてをリージョンの外に残します。フォームでは、通常、「メンバー変数、定数、およびプロパティ」、フォーム関数、およびイベント ハンドラーにグループ化します。繰り返しになりますが、イベント ハンドラーを確認するだけの場合でも、多くのテキストをスクロールする必要はありません。
私自身は #regions の方が好きですが、昔の同僚は物を隠すことに耐えられませんでした。7 つの #regions を含むページで作業したとき、彼の主張を理解しました。そのうちの少なくとも 3 つが自動生成され、同じ名前でした。散らかった。
#region を使用してコードを整理することに問題はありません。個人的には、通常、プロパティ、イベント ハンドラー、パブリック/プライベート メソッドなどに対してさまざまなリージョンをセットアップします。
Emacs にはフォールディング マイナー モードがありますが、私はたまにしか起動しません。ほとんどの場合、私が別の物理学者から継承された怪物に取り組んでいるときです。彼らは明らかに指導が少なかったか、コーディングの実践にあまり注意を払っていませんでした。
領域の使用 (またはコードの折りたたみ)は、コードの匂い (または非表示) や、人々に「簡単に」見られたくないコードを非表示にするその他のアイデアとは何の関係もありません。
領域とコードの折り畳みは、実際に、現在作業中の周りの無関係な「ノイズ」の量を最小限に抑えるために、折りたたむ/折り畳む/非表示にすることができるコードのセクションを簡単にグループ化する方法を提供することです。正しく設定すれば (リージョンに含まれるメソッドの名前のように実際に便利な名前を付けることを意味します)、現在編集している関数を除いてすべてを折りたたむことができ、他の関数を実際に見なくてもある程度のコンテキストを維持できます。コード行。
これらのアイデアには、おそらくいくつかのベスト プラクティス タイプ ガイドラインがあるはずですが、コード ファイルに標準的な構造を提供するために領域を広く使用しています (イベント、クラス全体のフィールド、プライベート プロパティ/メソッド、パブリック プロパティ/メソッドをグループ化しています)。各メソッドまたはプロパティには領域もあり、領域名はメソッド/プロパティ名です。オーバーロードされたメソッドがたくさんある場合、リージョン名は完全なシグネチャであり、そのグループ全体が関数名だけのリージョンにラップされます。
私は個人的に地域が嫌いです。私の意見では、リージョンに含める必要がある唯一のコードは、生成されたコードです。ファイルを開くときは、常に Ctrl+M+O から始めます。これはメソッド レベルに折りたたまれます。地域がある場合、地域名しか表示されません。
チェックインする前に、メソッド/フィールドを論理的にグループ化して、Ctrl+M+O の後で問題なく見えるようにします。地域が必要な場合は、クラスに多くの行が必要です。また、これは非常に一般的であることもわかりました。
リージョン ThisLooksLikeWellOrganizedCodeBecauseIUseRegions
// 全体のガベージ、ここには構造体はありません