Dlaczego powinieneś usuwać niepotrzebne C # używając dyrektyw?

216

Na przykład rzadko potrzebuję:

using System.Text;

ale zawsze jest tam domyślnie. Zakładam, że aplikacja zużyje więcej pamięci, jeśli kod zawiera niepotrzebne polecenia . Ale czy jest coś jeszcze, o czym powinienem wiedzieć?

Ponadto, czy ma to jakąkolwiek różnicę, jeśli ta sama dyrektywa o użyciu jest używana tylko w jednym pliku w porównaniu do większości / wszystkich plików?


Edycja: Zauważ, że to pytanie nie dotyczy niepowiązanej koncepcji zwanej instrukcją using , zaprojektowaną w celu ułatwienia zarządzania zasobami poprzez zapewnienie, że gdy obiekt wykracza poza zakres, wywoływana jest jego metoda IDisposable.Dispose . Zobacz zastosowania „za pomocą” w C # .

steffenj
źródło

Odpowiedzi:

181

Nie zmieni niczego podczas działania programu. Wszystko, co jest potrzebne, ładowane jest na żądanie. Więc nawet jeśli masz tę instrukcję using, chyba że faktycznie użyjesz typu w tej przestrzeni nazw / zestawie, zestaw, do którego ta instrukcja jest skorelowana, nie zostanie załadowany.

Głównie jest to po prostu sprzątanie według osobistych preferencji.

Darren Kopp
źródło
@francip - tak mówię. użycie nie wpływa na ładowanie zestawu, zestaw nie jest ładowany, dopóki nie zostanie przywołany typ zawarty w zestawie.
Darren Kopp,
69
ale może wpływać na czas kompilacji i szybkość reakcji Intellisense / IDE.
Marchy,
475

Jest to kilka powodów do usuwania nieużywany użyciu (S) / nazw, oprócz preferencji kodowania:

  • usunięcie nieużywanych klauzul za pomocą w projekcie może przyspieszyć kompilację, ponieważ kompilator ma mniej przestrzeni nazw do wyszukania typów wyszukiwania. (dotyczy to szczególnie C # 3.0 ze względu na metody rozszerzeń, w których kompilator musi przeszukać wszystkie przestrzenie nazw w celu znalezienia metod rozszerzenia w celu uzyskania lepszych dopasowań, wnioskowania o typie ogólnym i wyrażeń lambda obejmujących typy ogólne)
  • może potencjalnie pomóc uniknąć kolizji nazw w przyszłych kompilacjach, gdy nowe typy zostaną dodane do nieużywanych przestrzeni nazw, które mają taką samą nazwę jak niektóre typy w używanych przestrzeniach nazw.
  • zmniejszy liczbę pozycji na liście autouzupełniania edytora podczas kodowania, prawdopodobnie prowadząc do szybszego pisania (w C # 3.0 może to również zmniejszyć listę wyświetlanych metod rozszerzenia)

Co spowoduje usunięcie nieużywanych przestrzeni nazw :

  • zmieniać w jakikolwiek sposób dane wyjściowe kompilatora.
  • zmieniać w jakikolwiek sposób wykonanie skompilowanego programu (szybsze ładowanie lub lepsza wydajność).

Powstały zestaw jest taki sam z usuniętymi nieużywanymi zastosowaniami lub bez nich.

Pop Catalin
źródło
3
Kiedy zmodyfikujesz pliki, na końcu dodasz coraz więcej przestrzeni nazw na początku plików. Jeśli więc nie usuniesz nieużywanych przestrzeni nazw, po otwarciu pliku zobaczysz tylko ogromną listę przestrzeni nazw zamiast faktycznej implementacji.
Mert Akcakaya
5
Odnośnie szybszej kompilacji: Nieużywane usingdyrektywy w .csplikach mogą uniemożliwić usunięcie niektórych (w przeciwnym razie nieużywanych) odniesień do zestawu z .csprojprojektu. Jeśli masz „rozwiązanie” wielu projektów, niepotrzebne odniesienia między projektami wymuszą kompilację projektów w określonej kolejności, gdy w rzeczywistości są one niezależne i mogą być kompilowane równolegle. Dlatego usuń nieużywane usingdyrektywy, zanim sprawdzisz nieużywane odwołania do projektu w rozwiązaniu z wieloma projektami.
Jeppe Stig Nielsen
1
To świetne wytłumaczenie - ostatecznie nie ma to wiele wspólnego z wydajnością, ale raczej z najlepszymi praktykami. Dzięki za wyjaśnienie!
GSaunders,
39

Czystość kodu jest ważna.

Zaczyna się odczuwać, że kod może być nieobsługiwany i znajduje się na ścieżce browaru, gdy widzi się zbędne zastosowania. Zasadniczo, gdy widzę jakieś nieużywane stwierdzenia, w mojej głowie unosi się mała żółta flaga, która mówi mi „postępować ostrożnie”. A czytanie kodu produkcyjnego nigdy nie powinno dać tego wrażenia.

Więc posprzątaj swoje zastosowania. Nie bądź niechlujny. Inspiruj zaufanie. Uczyń swój kod ładnym. Daj innemu deweloperowi ciepłe uczucie.

rdzeń
źródło
To właśnie chciałem usłyszeć :-) Od czasu do czasu jestem przyzwyczajony do robienia czegoś Organize Usings -> Remove and Sort. BTW, dla mnie dwie górne opcje Organize Usingssą bez znaczenia. Mówię o VS2013 btw.
Sнаđошƒаӽ
30

Nie ma konstruktu IL, który odpowiada using. Więcusing instrukcje nie zwiększają pamięci aplikacji, ponieważ nie generuje się dla niej kodu ani danych.

Usingjest używany w czasie kompilacji tylko do celów rozpoznawania krótkich nazw typów na w pełni kwalifikowane nazwy typów. Zatem jedyny negatywny efekt jest niepotrzebnyusing może być , jest spowolnienie czasu kompilacji i zabranie nieco więcej pamięci podczas kompilacji. Jednak nie martwiłbym się tym.

Zatem jedynym prawdziwym negatywnym skutkiem posiadania usinginstrukcji, których nie potrzebujesz, jest inteligencja, ponieważ lista potencjalnych dopasowań do uzupełnienia podczas pisania zwiększa się.

Franci Penov
źródło
4

Możesz mieć konflikty nazw, jeśli wywołujesz swoje klasy tak jak (nieużywane) klasy w przestrzeni nazw. W przypadku System.Text będziesz mieć problem, jeśli zdefiniujesz klasę o nazwie „Encoder”.

W każdym razie jest to zwykle niewielki problem i wykrywany przez kompilator.

Pablo Fernandez
źródło
2

Twoja aplikacja nie będzie zużywać więcej pamięci. Kompilator znajduje klasy, których używasz w plikach kodu. To naprawdę nie boli poza tym, że nie jest czysty.

mattlant
źródło
2

Głównie są to osobiste preferencje. Oczyszczam je sam (Resharper ma dobrą robotę, mówiąc mi, kiedy nie ma potrzeby używania instrukcji).

Można powiedzieć, że może to skrócić czas kompilacji, ale przy dzisiejszych prędkościach komputera i kompilatora po prostu nie wywarłoby to zauważalnego wpływu.

Josh Sklare
źródło
2

Pozostawienie dodatkowych usingdyrektyw jest w porządku. Usunięcie ich ma niewielką wartość, ale niewiele. Na przykład sprawia, że ​​moje listy ukończenia IntelliSense są krótsze, a zatem łatwiejsze w nawigacji.

Zewnętrzne usingdyrektywy nie mają wpływu na skompilowane zestawy .

Czasami wkładam je do środka #regioni pozostawiam, że się zawaliło; dzięki temu przeglądanie pliku jest trochę czystsze. IMO, jest to jedno z niewielu dobrych zastosowań #region.

Jay Bazuzi
źródło
1
Można je zwinąć bez regionu
abatishchev
1
@abatishchev: Tak, to prawda w VS2010.
Jay Bazuzi
„Jedno z niewielu dobrych zastosowań #region”, więc masz na myśli używanie #regionw większości przypadków źle?
Steven
Tak, #regionpachnie kodem. Mówi, że za dużo dzieje się w twojej klasie.
Jay Bazuzi
2

jeśli chcesz utrzymać kod w czystości, nieużywane usinginstrukcje należy usunąć z pliku. korzyści wydają się bardzo wyraźne, gdy pracujesz w zespole współpracującym, który musi zrozumieć Twój kod, pomyśleć, że cały Twój kod musi być utrzymany, mniej kodu = mniej pracy, korzyści są długoterminowe.

Masd
źródło
1

Są one po prostu używane jako skrót. Na przykład musisz napisać: System.Int32 za każdym razem, jeśli nie masz używanego Systemu; na szczycie.

Usunięcie nieużywanych powoduje, że kod wygląda na czystszy.

Carra
źródło
1

Instrukcja using nie pozwala ci zakwalifikować używanych typów. Osobiście lubię je sprzątać. Naprawdę zależy to od sposobu użycia metryki loc

Ser5
źródło
1

Posiadanie tylko tych przestrzeni nazw, których faktycznie używasz, pozwala zachować dokumentację kodu.

Za pomocą dowolnego narzędzia wyszukiwania możesz łatwo znaleźć, które części kodu wywołują się nawzajem.

Jeśli masz nieużywane przestrzenie nazw, to nic nie znaczy podczas uruchamiania wyszukiwania.

Pracuję teraz nad czyszczeniem przestrzeni nazw, ponieważ ciągle jestem pytany, które części aplikacji uzyskują dostęp do tych samych danych w ten czy inny sposób.

Wiem, które części uzyskują dostęp do danych w każdy sposób, ponieważ dostęp do danych jest oddzielony przez przestrzenie nazw, np. Bezpośrednio przez bazę danych i bezpośrednio przez usługę internetową.

Nie mogę wymyślić prostszego sposobu na zrobienie tego wszystkiego naraz.

Jeśli chcesz, aby Twój kod był czarną skrzynką (dla programistów), to tak, to nie ma znaczenia. Ale jeśli musisz go utrzymywać z czasem, jest to cenna dokumentacja, podobnie jak każdy inny kod.

Timothy Gonzalez
źródło
0

Instrukcja „using” nie wpływa na wydajność, ponieważ jest jedynie pomocnikiem w kwalifikowaniu nazw twoich identyfikatorów. Zamiast wpisywać System.IO.Path.Combine (...) , możesz po prostu wpisać Path.Combine (...), jeśli używasz System.IO .

Jordan Parmer
źródło
0

Nie zapominaj, że kompilator wykonuje wiele pracy, aby zoptymalizować wszystko podczas budowania projektu. Używanie tego jest używane w wielu miejscach lub nie powinno być inaczej po skompilowaniu.

Patrick Desjardins
źródło