C＃で未使用のusingディレクティブを削除する理由

開発者UsingsがVisual Studio 2008で「未使用の削除」機能を使用する理由（ソースコードの片付け以外）があるかどうか疑問に思っています。

それらを取り出したい理由はいくつかあります。

• それは無意味です。付加価値はありません。
• ややこしい。その名前空間から何が使用されていますか？
• そうしないと、usingコードが時間の経過とともに変化するため、無意味なステートメントが徐々に蓄積されていきます。
• 静的解析は遅くなります。
• コードのコンパイルが遅くなります。

一方、それらを残す理由はそれほど多くありません。それらを削除する手間を省くことができると思います。しかし、あなたがその怠惰な人なら、もっと大きな問題を抱えています！

私は全く逆だと思います-不要な、不必要なusingステートメントを削除することは非常に役に立ちます。

3、6、9か月でコードに戻る必要があると想像してください。そうでなければ、誰かがコードを引き継いで保守する必要があります。

本当に必要ない使用ステートメントの膨大な長いリストがある場合、コードを見るとかなり混乱する可能性があります。その名前空間から何も使用されないのに、なぜそれがそこで使用されているのですか？

私は、プロの環境での長期的な保守性の観点から、コードをできるだけクリーンに保つことを強くお勧めします。これには、コードから不要なものをダンプすることも含まれます。乱雑さが減れば、混乱が減り、保守性が向上します。

マーク

これは非常に賢明な質問であるように私には思われます、それは人々が応答することによって非常にばかげた方法で扱われています。

ソースコードの変更は正当化する必要があると思います。これらの変更は隠れたコストを伴う可能性があり、質問をする人はこれを認識させたいと考えました。一人の人が軽蔑したように、彼らは「怠惰」と呼ばれることを求めませんでした。

Resharperを使い始めたばかりで、担当しているプロジェクトに対して警告やスタイルのヒントが出始めています。その中には、冗長なusingディレクティブの削除だけでなく、冗長な修飾子、大文字の使用なども含まれます。私の直感はコードを整頓し、すべてのヒントを解決することですが、私のビジネスヘッドは不当な変更に対して警告を出します。

私たちは自動ビルドプロセスを使用しているため、SVNリポジトリに変更を加えると、プロジェクト/バグ/問題にリンクできない変更が生成され、自動ビルドとリリースがトリガーされ、以前のバージョンに機能上の変更はありませんでした。

冗長な修飾子の削除を見ると、ドメインとデータレイヤーは修飾子によってのみ区別されているため、開発者を混乱させる可能性があります。

時系列の大文字の適切な使用法（つまり、ABCD-> Abcd）を見る場合、Resharperが参照クラス名を使用するXmlファイルをリファクタリングしないことを考慮に入れる必要があります。

したがって、これらのヒントに従うことは、見かけほど簡単ではなく、敬意を持って扱う必要があります。

すでに与えられた理由に加えて、それは不必要な名前の衝突を防ぎます。このファイルを考えてみましょう：

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

名前空間System.IOとSystem.Windows.Shapesの両方にそれぞれPathというクラスが含まれているため、このコードはコンパイルされません。フルクラスパスを使用して修正できます。

        private static string temporaryPath = System.IO.Path.GetTempFileName();

または、単に行を削除することもできusing System.Windows.Shapes;ます。

Intellisenseポップアップのオプションが少なくなりました（特に、名前空間に多数のExtensionメソッドが含まれている場合）。

理論的には、Intellisenseも高速です。

それらを削除します。確認するコードが少ないので、時間と混乱を節約できます。もっと多くの人に、シンプルできちんとした、きちんとしたものを維持してほしいと思います。それはあなたの部屋に汚れたシャツとズボンを持っているようなものです。それは醜く、なぜそこにあるのか不思議に思う必要があります。

また、未使用の使用法を削除した後、プロジェクトから一部のdll /プロジェクト参照を削除できると想定して、誤った循環依存関係を防止することもできます。

コードはより速くコンパイルされます。

最近、未使用のインポートを削除することが非常に役立ち、重要である別の理由がわかりました。

2つのアセンブリがあり、一方が他方を参照しているとしましょう（今のところ、最初のアセンブリと参照先を呼び出しAますB）。これで、Bに依存するコードがAにある場合、すべてが問題ありません。ただし、開発プロセスのある段階で、実際にはそのコードは不要であることに気付きますが、usingステートメントは元の場所に残します。今、あなたは無意味持っているだけでなく、using-directiveなく、アセンブリ参照にBどこにもなく、時代遅れのディレクティブで使用されていないが。これも最初にA、をBロードする必要があるため、コンパイルに必要な時間を増やします。

したがって、これは、コードがより簡潔で読みやすくなるだけでなく、参照されているすべてのアセンブリが存在しないプロダクションコードでアセンブリ参照を維持することに関する問題でもあります。

最後に、例ではBとAを一緒に出荷する必要がありましたが、BはAのどこでも使用されておらず、using-section で使用されています。これは、大規模な影響を与えますランタイムの-公演A時にロードするアセンブリを。

少なくとも理論的には、C＃.csファイル（または単一のプログラムソースコードファイル）が与えられた場合、コードを見て、必要なすべてをシミュレートする環境を作成できるはずです。いくつかのコンパイル/解析手法を使用して、自動的にそれを行うツールを作成することもできます。少なくともあなたがこれを心に留めておけば、コードファイルの内容をすべて理解できるはずです。

1000の.csファイルが与えられた場合、 using実際に使用されたのが10個しかないディレクティブを。外の世界を参照するコードで新しく導入されたシンボルを見るときはいつでも、それらの1000行を調べて、それが何であるかを理解する必要があります。これは明らかに上記の手順を遅くします。したがって、それらを10に減らすことができれば、役立ちます。

私の意見では、C＃usingディレクティブは非常に弱いものです。ジェネリック性を失うことなく単一のジェネリックシンボルを指定できず、usingエイリアスディレクティブを使用して拡張メソッドを使用できないためです。これは、Java、Python、Haskellなどの他の言語には当てはまりません。これらの言語では、（ほとんど）正確に外部から欲しいものを指定できます。ただし、イベントの場合は、using可能な限りエイリアスを使用することをお勧めします。