Які наслідки виникнення непотрібних посилань та використання?

12

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

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

c#

— MPelletier
джерело

5

Зауважте, що usings та посилання - це не одне і те ж. Багато відповідей не враховують це.

— фог

1

Якщо ви хочете зберегти код чистим і використовувати мінімум, подумайте про придбання ReSharper. Дивовижне розширення до Visual Studio. Я не можу жити / програмувати без цього. ;-)

— Андерс

1

stackoverflow.com/q/136278/3370168

— Азам

13

Інтелліссенс стане для вас набагато кориснішим, якщо ви будете usingмінімум, і це велика перевага.

Крім цього, я не думаю, що вигоди немає. Тож, можливо, компілятор C # буде працювати швидше, скажімо, на 1%; і що.

— Майк Накіс
джерело

1

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

— Мерф

C # IntelliSense все-таки трохи заплутався приблизно з 2005 року, коли вони почали скидати в список абсолютно все.

— Рей Міясака

@ReiMiyasaka, щоб ви отримали IntelliSense за все, що завгодно, а потім зробіть, Ctrl+.щоб швидко виправити "Додати простір імен XYZ"

— kizzx2

1

@Murph: незалежно від того, якою величиною буде накопичувальне значення 1%, воно все одно буде 1% від загальної сукупності, тому воно завжди буде несуттєвим. Крім того, компілятор не може знехтувати жодними usingsми, поки не з'ясує, що вони насправді є непотрібними, але він не може цього зрозуміти, якщо спочатку не скомпонував весь ваш вихідний файл. Як і у випадку з посиланнями на проекти, вони не відкидаються лише тому, що вони, здається, не використовуються, тому що вони можуть використовуватися динамічним (не виявляється під час компіляції) способом.

— Майк Накіс

1

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

— hmadrigal

9

Оскільки це практично тривіально досягти цього у Visual Studio (простий клацання правою кнопкою миші), чому б не зробити цього?

Це узгоджується з бритвою Occam , це просто звичайна техніка.

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

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

— JonnyBoats
джерело

+1, є надбудова, яка може зробити це для всього рішення. Це також нагадало мені про ClojureScript та Google Closure video, де важлива оптимізація всієї програми, оскільки типова веб-сторінка зараз становить близько 1 Мб. Це хороша звичка - чистити речі, які не потрібні.

— Робота

6

usingзаяви просто для того, щоб компілятор міг повністю посилатись на класи тощо. Додаткові usingоператори не матимуть істотного впливу на час компіляції.

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

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

— квентин-зірин
джерело

Очищення за допомогою є вбудованою особливістю VS 2010 (я теж думаю, що 2008). І ReSharper також може робити посилання. Але так, перш ніж я взятись до будь-якого масштабного очищення, я б задумався використовувати інструмент, щоб зробити це для мене.

— MPelletier

+1 для чіткого вираження різниці між невикористаними usings та невикористаними посиланнями. Два дуже різні!

— фог

1

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

Редагувати - Відповідно до дійсного коментаря, поданого нижче: Додаток все одно запускатиметься, якщо DLL не використовується та не постачається разом із програмою лише тому, що вона була додана до посилань. Щоб подбати про невикористані посилання в коді, ви можете переглянути: Видалення невикористаних посилань .

— Немає шансу
джерело

1

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

— фог

@phoog, дякую за ваш коментар. Принаймні, у .NET VS2010, якщо ви вручну додаєте посилання на рішення, DLL фізично додається до папки bin, навіть якщо ви не використовуєте його в коді.

— NoChance

1

Але якщо ви видалите DLL з папки bin або опублікуєте програму без DLL, програма все одно запуститься.

— фог

@phoog, ви праві, дякую, що вказали на це. Я відредагую публікацію.

— NoChance