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

Наприклад, мені рідко потрібні:

using System.Text;

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

Крім того, чи є якась різниця, якщо одна і та сама директива використовується лише в одному файлі проти більшості / всіх файлів?

Редагувати: Зауважте, що це питання не стосується неспорідненої концепції, яка називається користувачем , створеною для того, щоб допомогти керувати ресурсами, гарантуючи, що коли об'єкт виходить із сфери дії, його метод IDisposable.Dispose викликається. Див. Використання "використання" в C # .

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

В основному, це просто прибирати за особистими перевагами.

Там є кілька причин для видалення невикористаного використання (S) / просторів імен, крім кодування переваги:

• видалення невикористаних за допомогою пропозицій у проекті може зробити компіляцію швидшою, оскільки у компілятора є менше просторів імен для пошуку типів пошуку. (особливо це стосується C # 3.0 через методи розширення, де компілятор повинен шукати у всіх просторах імен для методів розширення для можливих кращих збігів, загального виводу типу та лямбда-виразів із залученням загальних типів)
• потенційно може допомогти уникнути зіткнення імен у майбутніх збірках, коли нові типи додаються до невикористаних просторів імен, які мають те саме ім'я, що і деякі типи у використаних просторах імен.
• зменшиться кількість елементів у списку автоматичного завершення редактора при кодуванні, що, можливо, призведе до більш швидкого введення тексту (у C # 3.0 це також може зменшити список показаних методів розширення)

Видалення невикористаних просторів імен не виконає:

• будь-яким чином змінити вихід компілятора.
• будь-яким чином змінити виконання скомпільованої програми (швидше завантаження або краща продуктивність).

Отримана збірка збігається з або без використання використаних (-ів) видалень.

Чистота коду є важливим.

Починає складатись відчуття, що код може бути недоторканим і на шляху коридору, коли ви бачите зайві вживання. По суті, коли я бачу якісь невикористані за допомогою висловлювань, у задній частині мозку піднімається маленький жовтий прапор, який каже мені "діяти обережно". І читання виробничого коду ніколи не повинно викликати у вас такого почуття.

Тож почистіть ваші пристосування. Не будьте неохайними. Надихайте впевненість. Зробіть свій код гарним. Подаруйте черговому дияволу тепле нечітке відчуття.

Не існує жодної конструкції ІЛ, яка б відповідала using. Таким чином, usingвисловлювання не збільшують пам’ять вашої програми, оскільки для неї не створюється код або дані.

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

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

У вас можуть виникнути сутички з іменами, якщо ви називаєте свої класи, як (невикористані) класи в просторі імен. У випадку System.Text у вас виникне проблема, якщо ви визначите клас під назвою "Енкодер".

У будь-якому випадку це, як правило, незначна проблема, і виявляється компілятором.

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

В основному це особисті переваги. Я сам їх прибираю (Решарпер добре допомагає мені говорити, коли немає необхідності використовувати заяви).

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

Залишити зайві usingдирективи - це добре. Їх видалення мало, але мало. Наприклад, це робить мої списки завершення IntelliSense коротшими, а отже, простішими в навігації.

На складені збори не впливають сторонні usingдирективи.

Іноді я поміщаю їх усередину a #regionі залишаю згорнутим; це робить перегляд файлу трохи чистішим. ІМО, це одне з небагатьох корисних застосувань #region.

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

Вони просто використовуються як ярлик. Наприклад, вам доведеться писати: System.Int32 кожен раз, якщо у вас не було системи, яка використовує; зверху.

Видалення невикористаних даних просто робить ваш код більш чистим.

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

Наявність лише просторів імен, які ви фактично використовуєте, дозволяє зберігати свій код документально.

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

Якщо у вас є невикористані простори імен, це означає, що нічого не означає під час пошуку.

Зараз я працюю над очищенням просторів імен, тому що мене постійно запитують, які частини програми так чи інакше отримують доступ до тих самих даних.

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

Я не можу придумати простіший спосіб зробити це все одночасно.

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

Оператор "using" не впливає на продуктивність, оскільки це лише помічник у визначенні імен ваших ідентифікаторів. Тож замість того, щоб вводити System.IO.Path.Combine (...) , ви можете просто ввести Path.Combine (...), якщо ви використовуєте System.IO .

Не забувайте, що компілятор робить багато роботи, щоб оптимізувати все під час створення вашого проекту. Використовуючи те, що використовується в багатьох місцях, або 1 не слід робити інший раз, коли компілюється.