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

Question

Мне интересно, есть ли какие-либо причины (кроме исправления исходного кода), почему разработчики используют функцию «Удалить неиспользуемые Usings» в Visual Studio 2008?

Answer 1

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

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

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

Answer 2

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

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

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

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

Марк

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

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

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

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

Answer 10

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

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

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