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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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 .

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.