Warum sollten Sie unnötiges C # mithilfe von Anweisungen entfernen?

Zum Beispiel brauche ich selten:

using System.Text;

aber es ist immer standardmäßig da. Ich gehe davon aus, dass die Anwendung mehr Speicher benötigt, wenn Ihr Code unnötige Anweisungen enthält . Aber gibt es noch etwas, das ich beachten sollte?

Macht es auch einen Unterschied, ob dieselbe Direktive in nur einer Datei im Vergleich zu den meisten / allen Dateien verwendet wird?

Bearbeiten: Beachten Sie, dass es bei dieser Frage nicht um das nicht verwandte Konzept geht, das als using-Anweisung bezeichnet wird. Es soll dazu beitragen, Ressourcen zu verwalten, indem sichergestellt wird, dass die IDisposable.Dispose- Methode aufgerufen wird , wenn ein Objekt den Gültigkeitsbereich verlässt . Siehe Verwendungen von "using" in C # .

Es ändert nichts, wenn Ihr Programm ausgeführt wird. Alles, was benötigt wird, wird auf Anfrage geladen. Selbst wenn Sie diese using-Anweisung haben, wird die Assembly, mit der using-Anweisung korreliert ist, nicht geladen, es sei denn, Sie verwenden tatsächlich einen Typ in diesem Namespace / dieser Assembly.

Hauptsächlich geht es nur darum, nach persönlichen Vorlieben aufzuräumen.

Neben der Codierungspräferenz gibt es nur wenige Gründe, nicht verwendete Benutzer mit (s) / Namespaces zu entfernen:

• Durch das Entfernen der nicht verwendeten using-Klauseln in einem Projekt kann die Kompilierung beschleunigt werden, da der Compiler weniger Namespaces zum Auflösen von Nachschlagetypen hat. (Dies gilt insbesondere für C # 3.0 aufgrund von Erweiterungsmethoden, bei denen der Compiler alle Namespaces nach Erweiterungsmethoden durchsuchen muss, um mögliche bessere Übereinstimmungen, generische Typinferenz und Lambda-Ausdrücke mit generischen Typen zu erhalten.)
• Dies kann möglicherweise dazu beitragen, Namenskollisionen in zukünftigen Builds zu vermeiden, wenn den nicht verwendeten Namespaces neue Typen hinzugefügt werden, die denselben Namen wie einige Typen in den verwendeten Namespaces haben.
• reduziert die Anzahl der Elemente in der automatischen Vervollständigungsliste des Editors beim Codieren, was möglicherweise zu einer schnelleren Eingabe führt (in C # 3.0 kann dies auch die Liste der angezeigten Erweiterungsmethoden verringern).

Was das Entfernen der nicht verwendeten Namespaces nicht bewirkt:

• Ändern Sie in irgendeiner Weise die Ausgabe des Compilers.
• Ändern Sie in irgendeiner Weise die Ausführung des kompilierten Programms (schnelleres Laden oder bessere Leistung).

Die resultierende Baugruppe ist mit oder ohne nicht verwendete Verwendung (en) identisch.

Die Sauberkeit des Codes ist wichtig.

Man bekommt das Gefühl, dass der Code möglicherweise nicht gepflegt ist und sich auf dem Browfield-Pfad befindet, wenn man überflüssige Verwendungen sieht. Im Wesentlichen, wenn ich sehe, dass einige Aussagen nicht verwendet werden, geht eine kleine gelbe Flagge in meinem Gehirn hoch und fordert mich auf, "mit Vorsicht vorzugehen". Und das Lesen von Produktionscode sollte Ihnen niemals dieses Gefühl geben.

Bereinigen Sie also Ihre Verwendungszwecke. Sei nicht schlampig. Vertrauen schaffen. Machen Sie Ihren Code hübsch. Geben Sie einem anderen Entwickler dieses warm-verschwommene Gefühl.

Es gibt kein IL-Konstrukt, das entspricht using. Daher usingerhöhen die Anweisungen nicht Ihren Anwendungsspeicher, da kein Code oder keine Daten dafür generiert werden.

Usingwird zur Kompilierungszeit nur verwendet, um kurze Typnamen in vollständig qualifizierte Typnamen aufzulösen. Der einzige negative Effekt, der unnötig sein usingkann, besteht darin, die Kompilierungszeit ein wenig zu verlangsamen und beim Kompilieren etwas mehr Speicherplatz zu beanspruchen. Darüber würde ich mir allerdings keine Sorgen machen.

Der einzige wirkliche negative Effekt von usingAnweisungen, die Sie nicht benötigen, ist Intellisense, da die Liste der möglichen Übereinstimmungen für die Fertigstellung während der Eingabe zunimmt.

Es kann zu Namenskonflikten kommen, wenn Sie Ihre Klassen wie die (nicht verwendeten) Klassen im Namespace aufrufen. Im Fall von System.Text tritt ein Problem auf, wenn Sie eine Klasse mit dem Namen "Encoder" definieren.

Auf jeden Fall ist dies normalerweise ein kleines Problem und wird vom Compiler erkannt.

Ihre Anwendung benötigt nicht mehr Speicher. Der Compiler kann Klassen finden, die Sie in den Codedateien verwenden. Es tut wirklich nicht weh, wenn man nicht sauber ist.

Es ist hauptsächlich persönliche Präferenz. Ich räume sie selbst auf (Resharper sagt mir gut, wenn es nicht nötig ist, Anweisungen zu verwenden).

Man könnte sagen, dass es die Zeit zum Kompilieren verkürzen könnte, aber mit Computer- und Compilergeschwindigkeiten heutzutage würde es einfach keine wahrnehmbaren Auswirkungen haben.

Zusätzliche usingAnweisungen zu hinterlassen ist in Ordnung. Es ist ein wenig wertvoll, sie zu entfernen, aber nicht viel. Zum Beispiel werden meine IntelliSense-Abschlusslisten dadurch kürzer und daher einfacher zu navigieren.

Die kompilierten Assemblys sind von externen usingAnweisungen nicht betroffen .

Manchmal lege ich sie in ein #regionund lasse es zusammengebrochen; Dies macht das Anzeigen der Datei etwas sauberer. IMO, dies ist eine der wenigen guten Anwendungen von #region.

Wenn Sie Ihren Code sauber halten möchten, sollten nicht verwendete usingAnweisungen aus der Datei entfernt werden. Die Vorteile werden sehr deutlich, wenn Sie in einem Team zusammenarbeiten, das Ihren Code verstehen muss. Denken Sie, dass Ihr gesamter Code beibehalten werden muss. Weniger Code = weniger Arbeit. Die Vorteile sind langfristig.

Sie werden nur als Verknüpfung verwendet. Zum Beispiel müssten Sie jedes Mal schreiben: System.Int32, wenn Sie kein using-System hätten; oben drauf.

Wenn Sie nicht verwendete entfernen, sieht Ihr Code nur sauberer aus.

Die using-Anweisung hindert Sie nur daran, die von Ihnen verwendeten Typen zu qualifizieren. Ich persönlich räume sie gerne auf. Es hängt wirklich davon ab, wie eine Loc-Metrik verwendet wird

Wenn Sie nur die Namespaces haben, die Sie tatsächlich verwenden, können Sie Ihren Code dokumentieren.

Mit jedem Suchwerkzeug können Sie leicht herausfinden, welche Teile Ihres Codes sich gegenseitig aufrufen.

Wenn Sie nicht verwendete Namespaces haben, bedeutet dies beim Ausführen einer Suche nichts.

Ich arbeite gerade daran, Namespaces zu bereinigen, da ich ständig gefragt werde, welche Teile der Anwendung auf die eine oder andere Weise auf dieselben Daten zugreifen.

Ich weiß, welche Teile auf beide Arten auf Daten zugreifen, da der Datenzugriff durch Namespaces getrennt ist, z. B. direkt über eine Datenbank und direkt über einen Webdienst.

Ich kann mir keinen einfacheren Weg vorstellen, dies alles auf einmal zu tun.

Wenn Sie nur möchten, dass Ihr Code eine Black Box ist (für die Entwickler), spielt das keine Rolle. Wenn Sie es jedoch im Laufe der Zeit warten müssen, ist es wie jeder andere Code eine wertvolle Dokumentation.

Die Anweisung "using" hat keinen Einfluss auf die Leistung, da sie lediglich dazu beiträgt, die Namen Ihrer Bezeichner zu qualifizieren. Anstatt also System.IO.Path.Combine (...) eingeben zu müssen , können Sie einfach Path.Combine (...) eingeben, wenn Sie System.IO verwenden .

Vergessen Sie nicht, dass der Compiler beim Erstellen Ihres Projekts viel Arbeit leistet, um alles zu optimieren. Die Verwendung wird an vielen Stellen verwendet, oder 1 sollte nach der Kompilierung keine andere Vorgehensweise ausführen.