C# で未使用の using ディレクティブを削除するのはなぜですか?

StackOverflow https://stackoverflow.com/questions/629667

  •  08-07-2019
  •  | 
  •  

質問

開発者が「未使用の削除」ツールを使用する理由は (ソース コードの整理とは別に) あるのではないかと考えています。 UsingsVisual Studio 2008 の機能?

役に立ちましたか？

解決

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

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

一方で、そのままにしておく理由はあまりありません。削除する手間が省けると思います。しかし、そこまで怠け者だと、さらに大きな問題が発生します。

他のヒント

私はまったく逆のことを言います。不要な using ステートメントを削除するのは非常に役立ちます。

3 か月、6 か月、9 か月後に自分のコードに戻らなければならないことを想像してください。そうしないと、他の誰かがコードを引き継いで保守しなければなりません。

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

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

マルク

私にはこれは非常に賢明な質問のように思えますが、回答者たちは非常に軽率に扱っています。

ソースコードへの変更は正当化される必要があると思います。これらの変更には隠れたコストがかかる可能性があり、質問者はこのことを知ってもらいたかったのです。彼らは、ある人が告発されたように「怠け者」と呼ばれることを望んでいませんでした。

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

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

冗長な修飾子の削除に注目すると、ドメイン層とデータ層のクラスは修飾子によってのみ区別されるため、開発者に混乱を引き起こす可能性があります。

略語の大文字化の適切な使用法を見てみると（すなわち、ABCD -> Abcd) その場合、Resharper はクラス名を参照するために使用する XML ファイルをリファクタリングしないことを考慮する必要があります。

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

Intellisense ポップアップのオプションが少なくなります (特に名前空間に多くの拡張メソッドが含まれている場合)。

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

すでに挙げた理由に加えて、不必要な名前の競合を防ぐことができます。次のファイルについて考えてみましょう。

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;.

それらを削除してください。調べて疑問に思うコードが減ると、時間と混乱が節約されます。もっと多くの人が物事をシンプル、きちんと、整頓した状態に保てるよう願っています。それは部屋に汚れたシャツやズボンがあるようなものです。それは醜いし、なぜそこにあるのか疑問に思うでしょう。

また、未使用の使用を削除した後、プロジェクトから一部の DLL/プロジェクト参照も削除できると仮定すると、誤った循環依存関係を防ぐのにも役立ちます。

コードのコンパイルが速くなります。

少なくとも理論上は、C# .cs ファイル (または任意の単一プログラム ソース コード ファイル) が与えられた場合、コードを確認して、必要なものすべてをシミュレートする環境を作成できるはずです。コンパイル/解析技術を使えば、それを自動的に行うツールを作成することもできます。これを少なくとも念頭に置いて実行すれば、コード ファイルの内容をすべて理解することができます。

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

私の意見では、C# using 汎用性を失わずに単一の汎用シンボルを指定することはできないため、ディレクティブは非常に弱いです。 using 拡張メソッドを使用するための alias ディレクティブ。これは、Java、Python、Haskell などの他の言語には当てはまりません。これらの言語では、外部の世界から必要なものを (ほぼ) 正確に指定できます。しかし、イベントが発生した場合は、使用することをお勧めします using 可能な限りエイリアス。

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

2 つのアセンブリがあり、一方が他方を参照していると想像してください (今は最初のものを呼び出しましょう) A そして参照された B）。A に B に依存するコードがある場合は、すべて問題ありません。しかし、開発プロセスのある段階で、実際にはそのコードはもう必要ないのに、using ステートメントを元の場所に残したことに気づきます。今、あなたは意味のないものを持っているだけではありません using-ディレクティブだけでなく、 アセンブリリファレンス に B これは、廃止されたディレクティブ以外では使用されていません。これにより、まずコンパイルに必要な時間が増加します。 A, 、 として B もロードする必要があります。

したがって、これはコードがクリーンで読みやすいという問題だけでなく、参照されるアセンブリのすべてが完全に参照されるわけではない運用コード内でのアセンブリ参照の維持の問題でもあります。 存在する.

最後に、この例では、B と A を一緒に出荷する必要がありましたが、B は A のどこにも使用されていませんが、 using-セクション。これは次のことに多大な影響を及ぼします ランタイム-のパフォーマンス A いつ 読み込み中 アセンブリ。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top