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


120

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


Я считаю, что это особенность PowerCommands для Visual Studio, а не самой Visual Studio.
Хосам Али,

3
В VS2008 это, безусловно, функция (наряду с возможностью сортировки операторов using) самой VS.
Ричард

1
@Hosam: PowerCommands позволяет сделать это для всего проекта / решения. Выполнение этого для каждого файла - это функция самой VS.
конфигуратор

3
Кстати, попробуйте Resharper, если вы хотите более точный контроль над такой очисткой.
Джон Феминелла,

2
Мне на самом деле очень не нравится эта функция - я неизменно обнаруживаю, что редактирую файл и мне приходится повторно добавлять все пространства имен System после того, как кто-то их очистил (обычно System, System.Collections.Generic и System.Linq.). Я обнаружил, что он добавляет больше трения, чем спасает. Теперь ваши собственные пространства имен проекта, а не пространства имен фреймворка - их имеет смысл очистить, чтобы прояснить проводку вашей программы. Хотелось бы, чтобы VS очищал импорт только из определенных пространств имен и оставлял системные, которые вам нужны чаще.
user1454265

Ответы:


186

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

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

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


59
Хороший программист ленив, он максимизирует работу, чтобы НЕ делать. : D
Николас Дориер

34
Я не согласен с тем, что хороший программист ленив, но я согласен с тональностью вашего утверждения. Хороший программист удалит их, чтобы сохранить свой код в чистоте и тем самым избежать будущей работы / проблем / проблем для себя и других.
Аллан,

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

5
Также есть смысл оставить стандартные пространства имен. В больших проектах и ​​командах их оставление в составе приводит к меньшему количеству потенциальных конфликтов слияния и меньшему количеству файлов для проверки кода. Вдобавок многие разработчики добавляют к вещам запутанные и труднодоступные методы расширения, и иногда поиск необходимых пространств имен для этих методов расширения является проблемой. Новые разработчики могут привыкнуть к включению System.Linq в их файлы кода и тратить много времени на то, чтобы выяснить, почему определенные методы недоступны, прежде чем обращаться за помощью.
Mark At Ramp51

5
Возможно, вы захотите оставить некоторые из них, чтобы intellisense не был чертовски глупым в будущем кодировании.
yazanpro

24

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

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

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

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

Марк


14

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

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

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

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

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

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

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


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

14

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

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


13

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

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


1
+1 для intellisense. На самом деле это медленно при запуске (я регулярно вижу «Создание кеша, попробуйте еще раз позже»), так что это может иметь большое значение. Время компиляции, о котором все говорят ... я еще не видел цифр.
Люк

5

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


4

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


3

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


5
Есть доказательства, подтверждающие это?
cjk

14
О, СК - ты снова поймал меня. Я солгал. Удаление ненужного текста фактически замедляет компиляцию кода. Подумайте об этом :)
Мертвый аккаунт

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

19
Было бы неплохо увидеть реальную статистику. Если при компиляции мы экономим всего несколько миллисекунд, то скорость не является веским аргументом. Однако есть и другие причины для удаления ненужных операторов using.
Грег,

3
Дело не во лжи или нет. Любой здравомыслящий человек догадается, что меньше беспорядка означает большую эффективность. «Свидетельство», подтверждающее это, состоит в том, чтобы придать ценность вашему ответу и поддержать аргумент, что «быстрее» не означает всего несколько миллисекунд, но на самом деле улучшенный опыт для более быстрой компиляции вашего проекта.
Матеус Фелипе

3

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

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

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

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


2

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.