ディレクティブを使用して不要なC＃を削除する必要があるのはなぜですか？

たとえば、私はめったに必要としません：

using System.Text;

しかし、デフォルトでは常にそこにあります。コードに不要なusingディレクティブが含まれている場合、アプリケーションはより多くのメモリを使用すると思います。しかし、他に知っておくべきことはありますか？

また、同じusingディレクティブが1つだけのファイルとほとんど/すべてのファイルで使用されている場合でも、違いはありますか？

編集：この質問は、オブジェクトがスコープ外に出たときにそのIDisposable.Disposeメソッドが呼び出されるようにすることでリソースを管理できるように設計された、usingステートメントと呼ばれる無関係な概念に関するものではないことに注意してください。C＃での「using」の使用を参照してください。

プログラムを実行しても何も変わりません。必要なものはすべてオンデマンドでロードされます。したがって、usingステートメントがあったとしても、その名前空間/アセンブリで実際に型を使用しない限り、usingステートメントが関連付けられているアセンブリは読み込まれません。

主に、個人的な好みのために片付けるだけです。

コーディング設定以外にも、未使用の使用/名前空間を削除する理由はいくつかあります。

• プロジェクト内の未使用のusing句を削除すると、コンパイラーが解決するルックアップタイプの名前空間が少なくなるため、コンパイルが速くなります。（これは、拡張メソッドがあるため、C＃3.0に特に当てはまります。コンパイラーは、すべての名前空間で拡張メソッドを検索し、一致の可能性、ジェネリック型の推論、およびジェネリック型を含むラムダ式を探す必要があります）
• 使用されている名前空間の一部のタイプと同じ名前を持つ未使用の名前空間に新しいタイプが追加されると、将来のビルドで名前の衝突を回避するのに役立つ可能性があります。
• コーディング時にエディターのオートコンプリートリストの項目数を減らし、タイピングを高速化する可能性があります（C＃3.0では、表示される拡張メソッドのリストも減らすことができます）

未使用の名前空間を削除しても何ができないのか：

• コンパイラの出力を何らかの方法で変更します。
• コンパイルされたプログラムの実行を何らかの方法で変更します（より高速なロード、またはより良いパフォーマンス）。

結果のアセンブリは、未使用の使用を削除してもしなくても同じです。

コードの清浄度は重要です。

不必要な使用法を見ると、コードが保守されていない可能性があり、眉毛の道にいると感じるようになります。本質的に、未使用のusingステートメントをいくつか見ると、脳の後ろに小さな黄色の旗が上がり、「注意して続行する」ように指示します。そして、量産コードを読むことは決してあなたにそのような気持ちを与えるべきではありません。

だからあなたの使用をきれいにします。だらしないでください。自信を呼び起こす。コードをきれいにしてください。別の開発者に、あたたかみのあるファジー感を与えます。

に対応するILコンストラクトはありませんusing。したがって、usingステートメントは生成されたコードやデータがないため、アプリケーションのメモリは増加しません。

Usingコンパイル時に、短い型名を完全修飾型名に解決する目的でのみ使用されます。したがって、不要な唯一のマイナスの影響usingは、コンパイル時間を少し遅くし、コンパイル中にメモリを少し多く取ることです。私はそれについては心配しません。

したがって、using入力中の補完候補のリストが増えるため、不要なステートメントを使用することによる唯一の真の悪影響はインテリセンスにあります。

名前空間で（未使用の）クラスのようなクラスを呼び出すと、名前が衝突する可能性があります。System.Textの場合、「Encoder」という名前のクラスを定義すると問題が発生します。

とにかく、これは通常は小さな問題であり、コンパイラによって検出されます。

アプリケーションはより多くのメモリを使用しません。コンパイラがコードファイルで使用するクラスを見つけるためのものです。それは本当にきれいでないことを超えて害はありません。

主に個人的な好みです。私はそれらを自分で片付けます（Resharperは、必要のないusingステートメントがある場合にそれを教えてくれます）。

コンパイルにかかる時間を短縮できると言えるかもしれませんが、最近のコンピューターとコンパイラの速度では、目に見える影響はありません。

余分なusingディレクティブを残しても問題ありません。それらを削除することには少し価値がありますが、多くはありません。たとえば、IntelliSense補完リストが短くなるため、ナビゲートしやすくなります。

コンパイルされたアセンブリは無関係の影響を受けません usingディレクティブの。

時々私はそれらをの中に入れ#region、それを折りたたんだままにします。これにより、ファイルの表示が少しきれいになります。IMO、これはのいくつかの優れた用途の1つです#region。

コードをクリーンに保ちたい場合は、使用されていないusingステートメントをファイルから削除する必要があります。コードを理解する必要があるコラボレーションチームで作業し、すべてのコードを保守する必要があると考え、コードが少ない=作業が少ない場合、メリットは長期的です。

それらはショートカットとしてのみ使用されます。たとえば、次のように記述する必要があります。使用するシステムがない場合は、毎回System.Int32。上に。

未使用のものを削除すると、コードがきれいに見えます。

usingステートメントを使用すると、使用する型を修飾できなくなります。私は個人的にそれらを片付けるのが好きです。本当にそれは場所のメトリックがどのように使用されるかに依存します

実際に使用する名前空間のみを使用すると、コードを文書化しておくことができます。

コードのどの部分が相互に呼び出しているかは、任意の検索ツールで簡単に見つけることができます。

未使用の名前空間がある場合、検索を実行しても意味はありません。

名前空間のクリーンアップに取り組んでいます。アプリケーションのどの部分が同じデータに何らかの方法でアクセスしているかを常に尋ねられるからです。

データベースから直接、またはWebサービスを介して間接的に、名前空間によってデータアクセスが分離されているため、どの部分がデータにアクセスしているかがわかります。

これを一度に行う簡単な方法は考えられません。

（開発者にとって）コードをブラックボックスにしたいだけであれば、問題はありません。しかし、それを長期間維持する必要がある場合は、他のすべてのコードと同様に貴重なドキュメントです。

「using」ステートメントは、識別子の名前を修飾するためのヘルパーにすぎないため、パフォーマンスには影響しません。したがって、System.IO.Path.Combine（...）と入力する代わりに、System.IOを使用している場合は、単にPath.Combine（...）と入力できます。

プロジェクトをビルドするとき、コンパイラはすべてを最適化するために多くの作業を行うことを忘れないでください。それを使用することは、多くの場所で使用されているか、コンパイル後に別のことを行うべきではありません。