開発者がVisualStudio2008の「未使用の削除Usings」機能を使用する理由（ソースコードの整理以外）があるのではないかと思います。
29152 次
10 に答える
193
それらを取り出したい理由はいくつかあります。
- それは無意味です。それらは価値を付加しません。
- ややこしい。その名前空間から何が使用されていますか？
- そうしないと、
usingコードが時間の経過とともに変化するにつれて、無意味なステートメントが徐々に蓄積されていきます。 - 静的解析は遅くなります。
- コードのコンパイルは遅くなります。
一方で、そのままにしておく理由はあまりありません。削除する手間を省くことができると思います。しかし、あなたがそんなに怠け者なら、あなたはもっと大きな問題を抱えています！
于 2009-03-10T11:03:01.857 に答える
14
これは非常に賢明な質問のように思えますが、回答者は非常に軽率に扱っています。
ソースコードの変更は正当化される必要があると思います。これらの変更には隠れたコストがかかる可能性があり、質問者はこれを認識したいと考えていました。彼らは「怠け者」と呼ばれることを求めませんでした。
私は ReSharper を使い始めたばかりで、私が担当しているプロジェクトに関する警告とスタイルのヒントを提供し始めています。その中には、冗長な using ディレクティブの削除だけでなく、冗長な修飾子、大文字化なども含まれています。私の本能は、コードを整理してすべてのヒントを解決することですが、ビジネス責任者は不当な変更に対して警告します。
私たちは自動化されたビルド プロセスを使用しているため、SVN リポジトリに変更を加えると、プロジェクト/バグ/問題にリンクできない変更が生成され、以前のバージョンに機能的な変更をもたらさない自動化されたビルドとリリースがトリガーされます。
冗長な修飾子の削除を見ると、ドメイン層とデータ層のクラスは修飾子によってのみ区別されるため、開発者が混乱する可能性があります。
アナクロニムの大文字化の適切な使用 (つまり、ABCD -> Abcd) を見ると、ReSharper は、参照クラス名を使用する Xml ファイルのいずれもリファクタリングしないことを考慮する必要があります。
したがって、これらのヒントに従うことは、見た目ほど単純ではなく、敬意を持って扱われるべきです。
于 2009-09-17T14:06:41.027 に答える
14
IntelliSense ポップアップのオプションが少なくなります (特に、名前空間に多数の拡張メソッドが含まれている場合)。
理論的には、IntelliSense も高速になるはずです。
于 2009-04-08T05:35:51.287 に答える
5
それらを削除します。調べたり考えたりするコードが少なくなるため、時間と混乱が軽減されます。もっと多くの人が物事をシンプルに、すっきりと整頓してくれることを願っています。部屋に汚れたシャツとズボンを置いているようなものです。それは醜く、なぜそこにあるのか不思議に思う必要があります。
于 2011-06-23T16:27:01.617 に答える
4
コードはより速くコンパイルされます。
于 2009-03-10T11:01:25.340 に答える
4
最近、未使用のインポートを削除することが非常に便利で重要である別の理由がわかりました。
2 つのアセンブリがあり、一方が他方を参照しているとします (ここでは、最初のアセンブリと参照先を呼び出しましょうA) B。A に B に依存するコードがある場合、すべて問題ありません。しかし、開発プロセスのある段階で、そのコードが実際にはもう必要ないことに気付きますが、using ステートメントはそのままにしておきます。これで、無意味なディレクティブだけでなく、廃止されたディレクティブ以外のどこにも使用されていないアセンブリ参照usingも作成されました。これにより、コンパイルに必要な時間が増加し、ロードも必要になります。BAB
したがって、これは、よりクリーンで読みやすいコードの問題であるだけでなく、参照されているアセンブリのすべてが存在するわけではない製品コードでのアセンブリ参照の維持の問題でもあります。
最後に、この例では、B と A を一緒に出荷する必要がありましたが、B は A のどこにも使用されておらず、usingセクションで使用されています。これは、アセンブリをロードするときのランタイムパフォーマンスに大きな影響を与えます。A
于 2016-03-03T09:22:43.887 に答える
3
また、未使用の使用法を削除した後にプロジェクトからいくつかのdll /プロジェクト参照を削除できることを前提として、誤った循環依存関係を防ぐのにも役立ちます。
于 2010-11-15T23:55:41.003 に答える
2
少なくとも理論上は、C# .cs ファイル (または単一のプログラム ソース コード ファイル) が与えられた場合、コードを見て、必要なものすべてをシミュレートする環境を作成できるはずです。何らかのコンパイル/解析手法を使用して、自動的に実行するツールを作成することもできます。少なくともこれを念頭に置いておけば、コード ファイルの内容をすべて理解することができます。
usingここで、1000 個のディレクティブを含む .cs ファイルが与えられ、実際に使用されたのは 10 個だけだったとします。外部の世界を参照するコードで新しく導入されたシンボルを見るときはいつでも、それが何であるかを理解するためにそれらの 1000 行を通過する必要があります。これにより、明らかに上記の手順が遅くなります。したがって、それらを 10 に減らすことができれば、それは役に立ちます。
私の意見では、C#usingディレクティブは非常に弱いものです。ジェネリック性が失われることなく単一のジェネリック シンボルを指定することはできず、usingエイリアス ディレクティブを使用して拡張メソッドを使用することもできないからです。これは、Java、Python、Haskell などの他の言語では当てはまりません。これらの言語では、外の世界から必要なものを (ほぼ) 正確に指定できます。それでも、using可能な限りエイリアスを使用することをお勧めします。
于 2014-02-26T02:57:43.537 に答える