Навіщо видаляти невикористані за допомогою директив у C #?

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

Є кілька причин, які ви хочете вивезти.

• Це безглуздо. Вони не додають ніякої цінності.
• Це заплутано. Що використовується з цього простору імен?
• Якщо цього не зробити, ви поступово будете накопичувати безглузді usingзаяви, оскільки ваш код змінюється з часом.
• Статичний аналіз повільніше.
• Складання коду відбувається повільніше.

З іншого боку, не так багато причин залишати їх. Я гадаю, що ви заощадите зусилля, щоб видалити їх. Але якщо ти такий ледачий, у тебе є більші проблеми!

Я б сказав зовсім протилежне - надзвичайно корисно видалити зайві, непотрібні за допомогою операторів.

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

Якщо у вас величезний довгий список білизни з використанням заяви, яка не дуже потрібна, погляд на код може бути дуже заплутаним. Чому це використовується там, якщо з цього простору імен нічого не використовується ??

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

Марк

Мені це здається дуже розумним питанням, на яке люди ставляться досить нескінченно, що люди відповідають.

Я б сказав, що будь-яка зміна вихідного коду має бути виправданою. Ці зміни можуть мати приховані витрати, і особа, яка ставить питання, хотіла про це знати. Вони не просили їх називати "ледачими", як спонукає одна людина.

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

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

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

Якщо я дивлюся на правильне використання великих букв анахронімів (тобто ABCD -> Abcd), то я маю враховувати, що Resharper не переробляє жоден з Xml-файлів, якими ми користуємося цими іменами довідкового класу.

Отже, слідування цим підказкам не настільки прямолінійно, як здається, і слід ставитися з повагою.

Окрім уже наведених причин, це запобігає непотрібним конфліктам імен. Розглянемо цей файл:

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

Менше варіантів у спливаючому віці Intellisense (особливо, якщо простори імен містять багато методів розширення).

Теоретично Intellisense також повинен бути швидшим.

Видаліть їх. Менше коду, який варто дивитись і дивуватися, економить час і плутанину. Я б хотів, щоб більше людей зберігали речі прості, акуратні та акуратні. Це як мати брудні сорочки та штани у своїй кімнаті. Це некрасиво, і ти мусиш задуматися, чому воно там.

Це також допомагає запобігти помилковим круговим залежностям, припускаючи, що ви також зможете видалити деякі посилання на проект dll / проекту після видалення невикористаних ужитків.

Код збирається швидше.

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

Уявіть, що у вас є дві збірки, де одна посилається на іншу (поки назвемо першу Aта посилається B). Тепер, коли у вас є код A, який залежить від B, все нормально. Однак на певному етапі процесу розробки ви помічаєте, що вам фактично вже не потрібен цей код, але ви залишаєте команду-оператор там, де вона була. Тепер у вас є не лише безглуздий using-направлення, але й посилання-збірка, на Bяку не використовується ніде, але в застарілій директиві. Це, по-перше, збільшує кількість часу, необхідного для складання A, як Bі завантаження.

Таким чином, це не тільки питання про більш чистий та легкий для читання код, але й про підтримку збірки-посилань у виробничому коді, де не всі згадані збірки навіть існують .

Нарешті, в нашому прикладі ми повинні були доставити B і A разом, хоча B не використовується ніде в A, а в using-секції. Це масово вплине на час виконання роботи Aпри завантаженні збірки.

Принаймні теоретично, якщо вам дали файл C # .cs (або будь-який файл вихідного коду програми), ви повинні мати можливість переглянути код і створити середовище, яке імітує все, що потрібно. З деякою технікою компіляції / розбору ви можете навіть створити інструмент для автоматичного виконання. Якщо ви це зробите принаймні на увазі, ви можете переконатися, що ви розумієте все, що пише файл коду.

Тепер подумайте, якщо вам дали файл .cs з 1000 usingдирективами, які фактично використовувались лише 10. Щоразу, коли ви дивитесь на символ, який знову вводиться в код, що посилається на зовнішній світ, вам доведеться пройти ці 1000 рядків, щоб зрозуміти, що це таке. Це, очевидно, сповільнює описану вище процедуру. Тож якщо ви зможете зменшити їх до 10, це допоможе!

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