performance - 冗長な修飾子の欠点はありますか? 何かメリットはありますか？

Question

たとえば、Datagrid だけではなく、System.Data.Datagrid として何かを参照します。例と説明を提供してください。ありがとう。

Answer 1

パフォーマンスに関しては、長所と短所はありません。すべてがコンパイル時に解決され、完全修飾名を使用するかどうかに関係なく、生成される MSIL は同じになります。

.NET の世界でその使用が普及している理由は、デザイナー マークアップなどの自動生成コードのためです。その場合、コード内にある可能性のある他のクラスと競合する可能性があるため、クラス名などの名前を完全修飾することをお勧めします。

ReSharper のようなツールを使用している場合は、完全修飾された参照のうち不要なものを実際に教えてくれるので (たとえば、それらをグレー表示することによって)、それらを取り除くことができます。さまざまなコード ベースでコードを頻繁にカットアンドペーストする場合は、それらを完全に修飾する必要があります。(繰り返しますが、なぜいつもカットアンドペーストをしたいのでしょうか? それは悪い形のコード再利用です!)

Answer 2

参照している型について非常に明示的であり、それは利点です。ただし、まったく同じプロセスで、コードの明確さをあきらめています。これは、コードを読みやすく理解しやすいものにしたいため、私の場合は明らかにマイナス面です。クラスへの明示的な参照でのみ解決できる異なる名前空間で競合がない限り、短いバージョンを使用します..キーワードを使用してエイリアスを作成しない限り:

using Datagrid = System.Data.Datagrid;

Answer 3

実際のフルパスはglobal::System.Data.DataGrid. より修飾されたパスを使用するポイントは、特に別の using の導入によって型解決で問題が発生する場合に、追加の using ステートメントを使用する必要がないようにすることです。明示的にする必要があるときに明示的にできるように、より完全修飾された識別子が存在しますが、クラスの名前空間が明確であれば、DataGrid多くの人にとってバージョンがより明確になります。

Answer 4

利点は、使用するすべてのものにインポートを追加する必要がないことです。特に、それが特定の名前空間から使用する唯一のものである場合は、衝突も防止されます。

もちろん、欠点は、特定の修飾子を使用すればするほど、コードのサイズが大きくなり、読みにくくなることです。

個人的には、特定の名前空間の何かを 1 回か 2 回しか使用しないことが確実にわかっていない限り、ほとんどの場合にインポートを使用する傾向があるため、コードの読みやすさには影響しません。

Answer 5

私は通常、コードをできるだけクリーンで読みやすいものにするために、利用可能な最短の形式を使用します。結局のところ、それが using ディレクティブの目的であり、VS エディターのツールチップにより、型の出自に関する詳細がすぐにわかります。

また、COM 相互運用レイヤーで RCW の名前空間タグを使用して、コード内でこれらの変数を明示的に呼び出す傾向があります (ライフサイクルとコレクションに特別な注意が必要な場合があります)。

using _Interop = Some.Interop.Namespace;

Answer 6

読みやすさとコーディングに費やされる実際の時間だけです。一般に、あいまいなオブジェクトを含む名前空間がない場合、それは本当に必要ないと思います。考慮すべきもう1つのことは、使用レベルです。リフレクションを使用するメソッドが 1 つあり、System.Reflection を 10 回入力しても問題ない場合は、大した問題ではありませんが、名前空間を頻繁に使用する予定がある場合は、インクルードをお勧めします。

Answer 7

状況に応じて、余分な修飾子が警告を生成します (これが冗長の意味である場合)。警告をエラーとして扱う場合、それはかなり深刻な欠点です。

たとえば、GCCでこれに遭遇しました。

struct A {
    int A::b; // warning!
}