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

Istnieje jest kilka powodów do usuwania nieużywanych przestrzeni nazw, poza preferencjami kodowania:

• usunięcie nieużywanych klauzul using w projekcie może przyspieszyć kompilację, ponieważ kompilator ma mniej przestrzeni nazw do wyszukiwania typów do rozwiązania. (szczególnie dotyczy to C# 3.0 z powodu metod extension, gdzie kompilator musi przeszukiwać wszystkie przestrzenie nazw w poszukiwaniu metod extension dla możliwych lepszych dopasowań, Typ generic inference i wyrażenia lambda zawierające rodzaje rodzajowe)
• może potencjalnie pomóc uniknąć kolizji nazw w przyszłych kompilacjach, gdy nowe typy są dodawane 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, co może prowadzić do szybszego pisania (w C# 3.0 może to również zmniejszyć listę pokazanych metod rozszerzeń)

Co usunięcie nieużywanych przestrzeni nazw nie zrobi :

• alter in any way wyjście kompilatora.
• zmienia w jakikolwiek sposób wykonanie skompilowanego programu (szybsze ładowanie lub lepsza wydajność).

Powstały zespół jest taki sam z lub bez nieużywanych using(S) usunięte.

Czystość kodu jest ważna.

Zaczyna się czuć, że kod może być niezabezpieczony i na ścieżce browfield, gdy widzi się zbędne użycie. W istocie, kiedy widzę kilka niewykorzystanych wypowiedzi, z tyłu mojego mózgu pojawia się mała żółta flaga, która mówi mi, żebym " postępował ostrożnie."A czytanie kodu produkcyjnego nigdy nie powinno dać ci tego uczucia.

Więc posprzątaj po sobie. Nie bądź niechlujny. Wzbudzaj zaufanie. Popraw swój kod. Dać kolejny dev tak ciepły-rozmyte uczucie.

Nie ma konstrukcji IL, która odpowiada using. Tak więc, polecenia using nie zwiększają pamięci aplikacji, ponieważ nie ma kodu ani danych, które są dla niej generowane.

Using jest używany w czasie kompilacji tylko do celów rozdzielania krótkich nazw typów na w pełni kwalifikowane nazwy typów. Tak więc jedynym negatywnym efektem, jaki może mieć using, jest spowolnienie czasu kompilacji i pobranie trochę więcej pamięci podczas kompilacji. Nie martwiłbym się o to. chociaż.

Tak więc, jedynym prawdziwym negatywnym efektem posiadania using wypowiedzi, których nie potrzebujesz, jest intellisense, ponieważ zwiększa się lista potencjalnych dopasowań do ukończenia podczas pisania.

Możesz mieć konflikty nazw, jeśli wywołasz swoje klasy jak (nieużywane) klasy w przestrzeni nazw. W przypadku systemu.Tekst, będziesz miał problem, jeśli zdefiniujesz klasę o nazwie "Encoder".

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

Twoja aplikacja nie będzie zużywać więcej pamięci. To dla kompilatora, aby znaleźć klasy, których używasz w plikach kodu. To naprawdę nie boli poza nie jest czysty.

To głównie osobiste preferencje. Sam je czyszczę (Resharper dobrze mi mówi, gdy nie ma potrzeby używania oświadczeń).

Można by powiedzieć, że może to skrócić czas kompilacji, ale z prędkością komputera i kompilatora w dzisiejszych czasach nie miałoby to żadnego zauważalnego wpływu.

Zostawianie dodatkowych using dyrektyw jest w porządku. Jest trochę wartości w ich usuwaniu, ale niewiele. Na przykład sprawia, że moje listy dopełnień IntelliSense są krótsze, a tym samym łatwiejsze w nawigacji.

Skompilowane zespoły nie są objęte zewnętrznymi dyrektywami using.

Czasami umieszczam je wewnątrz #region i zostawiam je zwinięte; to sprawia, że przeglądanie pliku jest trochę czystsze. IMO, jest to jedno z niewielu dobrych zastosowań #region.

Jeśli chcesz zachować czysty kod, nieużywane instrukcje using powinny zostać usunięte z pliku. korzyści wydają się bardzo jasne, gdy pracujesz w zespołowym zespole, który musi zrozumieć Twój kod, myśleć, że cały Twój kod musi być utrzymany, mniej kodu = mniej pracy, korzyści są długoterminowe.

Są używane tylko jako skrót. Na przykład, trzeba by napisać: System.Int32

Usunięcie nieużywanych sprawia, że Twój kod wygląda czystiej.

Instrukcja using po prostu uniemożliwia kwalifikowanie typów, których używasz. Osobiście lubię je sprzątać. Tak naprawdę to zależy od tego, jak używana jest metryka loc

Posiadanie tylko przestrzeni nazw, których faktycznie używasz, pozwala zachować dokumentowany kod.

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

Jeśli masz nieużywane przestrzenie nazw, to nic nie znaczy, gdy uruchamiasz wyszukiwanie.

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

Wiem, które części mają dostęp do danych w każdy sposób ze względu na oddzielenie dostępu do danych przez przestrzenie nazw np. bezpośrednio przez bazę danych i bezpośrednio przez serwis internetowy.

Nie mogę wymyślić prostszego sposobu, aby zrobić to wszystko na raz.

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

Instrukcja "using" nie ma wpływu na wydajność, ponieważ jest jedynie pomocnikiem w kwalifikowaniu nazw identyfikatorów. Zamiast więc wpisywać System. IO. Path. Combine (...) , możesz po prostu wpisać Path.Combine(...) Jeśli masz za pomocą System.IO .

Nie zapominaj, że kompilator wykonuje wiele pracy, aby zoptymalizować wszystko podczas budowania Twojego projektu. Użycie, które jest używane w wielu miejscach lub 1 nie powinno robić innego po skompilowaniu.