たとえば、私はめったに必要ありません：
using System.Text;
ただし、デフォルトでは常に存在します。コードに不要なusingディレクティブが含まれている場合、アプリケーションはより多くのメモリを使用すると思います。しかし、他に知っておくべきことはありますか？
また、同じusingディレクティブが1つのファイルだけで使用されている場合と、ほとんど/すべてのファイルで使用されている場合でも、違いはありますか？
編集：この質問は、オブジェクトがスコープ外になったときにそのIDisposable.Disposeメソッドが呼び出されるようにすることでリソースを管理できるように設計された、 usingステートメントと呼ばれる無関係の概念に関するものではないことに注意してください。C＃での「使用」の使用を参照してください。
コーディングの好み以外にも、未使用の using(s)/namespace を削除する理由はいくつかあります。
未使用の名前空間を削除してもできないこと:
結果として得られるアセンブリは、未使用の使用を削除してもしなくても同じです。
プログラムの実行時に何も変更されません。必要なものはすべてオンデマンドでロードされます。したがって、そのusingステートメントがある場合でも、その名前空間/アセンブリで実際に型を使用しない限り、usingステートメントが関連付けられているアセンブリはロードされません。
主に、個人的な好みのためにクリーンアップするだけです。
コードのクリーン度は重要です。
余分な使用法が見られると、コードが保守されておらず、ブロウフィールド パス上にある可能性があると感じ始めます。要するに、未使用の using ステートメントを目にすると、脳の奥に小さな黄色のフラグが立ち、「注意して続行する」ように伝えます。そして、製品コードを読んでも、決してそのような感覚を覚えてはいけません。
だからあなたの使用法をきれいにしてください。だらしなくしないでください。自信を刺激します。コードをきれいにします。別の開発者に、あたたかいファジー感を与えます。
に対応する IL コンストラクトはありませんusing。したがって、usingステートメント用に生成されるコードやデータがないため、ステートメントによってアプリケーションのメモリが増加することはありません。
Using短い型名を完全修飾型名に解決する目的でのみ、コンパイル時に使用されます。したがって、不要な唯一のマイナスの影響usingは、コンパイル時間が少し遅くなり、コンパイル中に少し多くのメモリが必要になることです。私はそれについて心配することはありません。
したがって、必要のないステートメントを持つことによる唯一の実際のマイナス効果は、using入力中に補完される可能性のある一致のリストが増加するため、IntelliSense です。
名前空間の (未使用の) クラスのようにクラスを呼び出すと、名前が衝突する可能性があります。System.Text の場合、「Encoder」という名前のクラスを定義すると問題が発生します。
とにかく、これは通常、マイナーな問題であり、コンパイラによって検出されます。
using余分なディレクティブを残しておくのは問題ありません。それらを削除することには少し価値がありますが、それほど多くはありません。たとえば、IntelliSense補完リストが短くなるため、ナビゲートしやすくなります。
コンパイルされたアセンブリは、無関係なusingディレクティブの影響を受けません。
時々私はそれらをの中に入れて#region、それを折りたたんだままにしておきます。これにより、ファイルの表示が少しきれいになります。IMO、これはの数少ない良い使い方の1つです#region。
アプリケーションはそれ以上のメモリを使用しません。コンパイラは、コードファイルで使用するクラスを見つけるためのものです。それは本当にきれいでないことを超えて害はありません。
主に個人的な好みです。私はそれらを自分でクリーンアップします（ReSharperは、不要なusingステートメントがある場合にそれを教えてくれます）。
コンパイルにかかる時間が短縮される可能性があると言えますが、最近のコンピューターとコンパイラーの速度では、知覚できるほどの影響はありません。
それらはショートカットとして使用されます。たとえば、using Systemがない場合は、毎回System.Int32と記述する必要があります。上に。
未使用のものを削除すると、コードがすっきりと見えます。
using ステートメントは、使用する型を修飾できないようにするだけです。私は個人的にそれらをきれいにするのが好きです。実際には、loc メトリックの使用方法に依存します
実際に使用する名前空間のみを保持することで、コードを文書化しておくことができます。
任意の検索ツールを使用して、コードのどの部分が相互に呼び出しているかを簡単に見つけることができます。
未使用の名前空間がある場合、検索を実行しても意味がありません。
私は現在、名前空間のクリーンアップに取り組んでいます。アプリケーションのどの部分が何らかの方法で同じデータにアクセスしているのかを常に尋ねられるからです。
データベースを介して直接アクセスしたり、Web サービスを介して間接的にアクセスしたりするなど、名前空間によってデータ アクセスが分離されているため、どの部分がそれぞれの方法でデータにアクセスしているかがわかります。
これを一度に行う簡単な方法は考えられません。
コードを (開発者にとって) ブラック ボックスにしたいだけなら、問題ありません。しかし、長期間維持する必要がある場合は、他のすべてのコードと同様に貴重なドキュメントです。
'using'ステートメントは、識別子の名前を修飾するための単なるヘルパーであるため、パフォーマンスに影響を与えません。したがって、System.IO.Path.Combine（...）と入力する代わりに、System.IOを使用している場合は、Path.Combine（...）と入力するだけで済みます。
プロジェクトをビルドするとき、コンパイラはすべてを最適化するために多くの作業を行うことを忘れないでください。それを使用することは多くの場所で使用されます、または1はコンパイルされた後は別のことをするべきではありません。