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 # .
źródło
Jest to kilka powodów do usuwania nieużywany użyciu (S) / nazw, oprócz preferencji kodowania:
Co spowoduje usunięcie nieużywanych przestrzeni nazw :
Powstały zestaw jest taki sam z usuniętymi nieużywanymi zastosowaniami lub bez nich.
źródło
using
dyrektywy w.cs
plikach mogą uniemożliwić usunięcie niektórych (w przeciwnym razie nieużywanych) odniesień do zestawu z.csproj
projektu. 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żywaneusing
dyrektywy, zanim sprawdzisz nieużywane odwołania do projektu w rozwiązaniu z wieloma projektami.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.
źródło
Organize Usings -> Remove and Sort
. BTW, dla mnie dwie górne opcjeOrganize Usings
są bez znaczenia. Mówię o VS2013 btw.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.Using
jest 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
using
instrukcji, których nie potrzebujesz, jest inteligencja, ponieważ lista potencjalnych dopasowań do uzupełnienia podczas pisania zwiększa się.źródło
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.
źródło
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.
źródło
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.
źródło
Pozostawienie dodatkowych
using
dyrektyw 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
using
dyrektywy nie mają wpływu na skompilowane zestawy .Czasami wkładam je do środka
#region
i pozostawiam, że się zawaliło; dzięki temu przeglądanie pliku jest trochę czystsze. IMO, jest to jedno z niewielu dobrych zastosowań#region
.źródło
#region
”, więc masz na myśli używanie#region
w większości przypadków źle?#region
pachnie kodem. Mówi, że za dużo dzieje się w twojej klasie.jeśli chcesz utrzymać kod w czystości, nieużywane
using
instrukcje 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.źródło
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.
źródło
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
źródło
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.
źródło
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 .
źródło
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.
źródło