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

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

  •  08-07-2019
  •  | 
  •  

Вопрос

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

Это было полезно?

Решение

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

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

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

Другие советы

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

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

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

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

Марк

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

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

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

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

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

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

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

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

Теоретически 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();

или мы могли бы просто удалить строку , используя System.Windows.Shapes; .

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top