Зачем использовать неиспользуемые директивы в С#?

Ответ 1

Есть несколько причин, по которым вы захотите их вынуть.

• Это бессмысленно. Они не добавляют значения.
• Это сбивает с толку. Что используется в этом пространстве имен?
• Если вы этого не сделаете, вы постепенно накапливаете бессмысленные операторы using, так как ваш код изменяется со временем.
• Статический анализ медленнее.
• Компиляция кода медленнее.

С другой стороны, их не так много. Я полагаю, вы избавляете себя от необходимости удалять их. Но если вы ленивы, у вас большие проблемы!

Ответ 2

Я бы сказал совсем наоборот - очень полезно удалять ненужные, ненужные с помощью утверждений.

Представьте, что вам нужно вернуться к вашему коду через 3, 6, 9 месяцев - или кто-то другой должен взять ваш код и сохранить его.

Если у вас есть огромный длинный список стилей использования инструкции, которая на самом деле не нужна, просмотр кода может быть довольно запутанным. Почему это используется там, если из этого пространства имен ничего не используется?

Я предполагаю, что с точки зрения долгосрочной ремонтопригодности в профессиональной среде я бы настоятельно рекомендовал сохранить ваш код как можно более чистым, и это включает в себя сброс ненужных вещей из него. Меньше беспорядка означает меньше путаницы и, следовательно, более высокую ремонтопригодность.

Марк

Ответ 3

Мне кажется, что это очень разумный вопрос, к которому люди реагируют довольно легкомысленно.

Я бы сказал, что любое изменение исходного кода должно быть оправдано. Эти изменения могут иметь скрытые издержки, и человек, задающий вопрос, хотел быть осведомленным об этом. Они не просили, чтобы их называли "ленивыми", так как один человек был лишен.

Я только что начал использовать Resharper, и он начинает давать предупреждения и подсказки стиля для проекта, за который я несу ответственность. Среди них - удаление избыточной директивы, но также избыточные квалификаторы, капитализация и многое другое. Мой инстинкт кишки заключается в том, чтобы привести в порядок код и решить все намеки, но мой бизнес-глава предупреждает меня о неоправданных изменениях.

Мы используем автоматизированный процесс сборки, поэтому любые изменения в нашем репозитории SVN будут генерировать изменения, которые мы не могли бы связывать с проектами/ошибками/проблемами, и приводили к автоматическим сбоям и выпускам, которые не приводили к функциональным изменениям предыдущих версий.

Если мы посмотрим на удаление избыточных квалификаторов, это может привести к путанице с разработчиками в качестве классов, которые наши уровни "Домены" и "Данные" дифференцируются только по квалификаторам.

Если я посмотрю на правильное использование капитализации анахронимов (т.е. ABCD → Abcd), то я должен принять во внимание, что Resharper не реорганизует ни один из Xml файлов, которые используют эти имена ссылочных классов.

Итак, следующие эти подсказки не так прямолинейны, как кажется, и к ним следует относиться с уважением.

Ответ 4

Меньше параметров в всплывающем окне Intellisense (особенно, если пространства имен содержат множество методов расширения).

Теоретически Intellisense также должен быть быстрее.

Ответ 5

В дополнение к уже указанным причинам он предотвращает ненужные конфликты имен. Рассмотрим этот файл:

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

Ответ 6

Удалите их. Меньше кода, чтобы смотреть и удивляться, что экономит время и путаницу. Я желаю, чтобы больше людей ХРАНИЛИ ВЕЩИ ПРОСТО, НЕАТ И ТИДИ. Это как грязные рубашки и брюки в вашей комнате. Это уродливо, и вы должны удивляться, почему он там.

Ответ 7

Он также помогает предотвратить ложные циклические зависимости, предполагая, что вы также можете удалить некоторые ссылки dll/project из вашего проекта после удаления неиспользуемых файлов.

Ответ 8

Кодекс компилируется быстрее.

Ответ 9

По крайней мере, теоретически, если вам был предоставлен файл С#.cs(или любой файл исходного кода одной программы), вы должны иметь возможность посмотреть на код и создать среду, которая имитирует все, что ей нужно. С помощью некоторых методов компиляции/разбора вы даже можете создать инструмент для этого автоматически. Если это сделано вами, по крайней мере, вы можете понять, что вы знаете все, что говорит код.

Теперь рассмотрим, если вам был предоставлен файл .cs с 1000 using директивами, которые фактически использовались только 10. Всякий раз, когда вы смотрите на символ, который недавно появился в коде, который ссылается на внешний мир, вам придется пройти через эти 1000 строк, чтобы выяснить, что это такое. Это, очевидно, замедляет описанную выше процедуру. Поэтому, если вы можете уменьшить их до 10, это поможет!

На мой взгляд, директива С# using очень слабая, поскольку вы не можете указать один общий символ без потери целостности, и вы не можете использовать директиву using alias для использования методов расширения. Это не относится к другим языкам, таким как Java, Python и Haskell, на тех языках, на которых вы можете указать (почти) именно то, что вы хотите от внешнего мира. Но тогда я предлагаю использовать псевдоним using, когда это возможно.

Ответ 10

Недавно у меня появилась еще одна причина, по которой удаление неиспользуемых импортов весьма полезно и важно.

Представьте, что у вас есть две сборки, где одна ссылается на другую (теперь давайте назовем первую A и ссылку B). Теперь, когда у вас есть код в A, который зависит от B, все в порядке. Однако на каком-то этапе вашего процесса разработки вы замечаете, что вам действительно не нужен этот код, но вы оставите его с помощью инструкции. Теперь у вас есть не только бессмысленный using -directive, но и assembly-reference до B, который не используется нигде, кроме устаревшей директивы. Это во-первых увеличивает время, необходимое для компиляции A, так как должен быть загружен B.

Таким образом, это не только проблема с более чистым и понятным кодом, но и поддержка ссылок на сборки в производственном коде, где даже не все эти ссылочные сборки даже существуют.

Наконец, в нашем предисловии нам пришлось отправить B и A вместе, хотя B не используется нигде в A, а в разделе using. Это существенно повлияет на производительность во время выполнения A при загрузке сборки.