Die allgemeinere Frage:
Haben Sie jemals von einem solchen Standard gehört? Wenn ja, aus welchem Grund?
Ja, ich habe davon gehört und die Verwendung von vollständig qualifizierten Objektnamen verhindert Namenskollisionen. Wenn sie vorkommen, sind sie zwar selten, können aber außerordentlich schwierig zu ermitteln sein.
Ein Beispiel:
Dieser Typ eines Szenarios wird wahrscheinlich besser mit einem Beispiel erklärt.
Nehmen wir an, wir haben zwei, Lists<T>die zu zwei separaten Projekten gehören.
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
Wenn wir den vollständig qualifizierten Objektnamen verwenden, ist klar, welcher List<T>verwendet wird. Diese Klarheit geht natürlich zu Lasten der Ausführlichkeit.
Und Sie könnten argumentieren: "Warten Sie! Niemand würde jemals zwei Listen wie diese verwenden!" An dieser Stelle werde ich auf das Wartungsszenario hinweisen.
Sie haben ein Modul Foofür Ihr Unternehmen geschrieben, das das genehmigte, optimierte Unternehmen verwendet List<T>.
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
Später beschließt ein neuer Entwickler, die von Ihnen geleistete Arbeit zu erweitern. Da sie die Standards des Unternehmens nicht kennen, aktualisieren sie den usingBlock:
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
Und Sie können sehen, wie die Dinge in Eile schlecht laufen.
Es sollte trivial sein, darauf hinzuweisen, dass Sie zwei proprietäre Klassen mit demselben Namen, jedoch in unterschiedlichen Namespaces innerhalb desselben Projekts haben können. Es geht also nicht nur darum, mit von .NET Framework bereitgestellten Klassen zu kollidieren.
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
Die Realität:
Tritt dies wahrscheinlich in den meisten Projekten auf? Nein nicht wirklich. Wenn Sie jedoch an einem großen Projekt mit vielen Eingaben arbeiten, tun Sie Ihr Bestes, um die Gefahr von Explosionen auf Sie zu minimieren.
Große Projekte mit mehreren beitragenden Teams sind eine besondere Art von Tier in der Anwendungswelt. Regeln, die für andere Projekte unangemessen erscheinen, werden aufgrund der Eingabeströme für das Projekt und der Wahrscheinlichkeit, dass die Beitragenden die Projektrichtlinien nicht gelesen haben, relevanter.
Dies kann auch auftreten, wenn zwei große Projekte zusammengeführt werden. Wenn beide Projekte ähnlich benannte Klassen hatten, werden Kollisionen angezeigt, wenn Sie von einem Projekt zum anderen referenzieren. Und die Projekte sind möglicherweise zu umfangreich, um sie umzugestalten, oder das Management genehmigt nicht die Kosten für die Finanzierung der für die Umgestaltung aufgewendeten Zeit.
Alternativen:
Sie haben zwar nicht gefragt, aber es lohnt sich darauf hinzuweisen, dass dies keine großartige Lösung für das Problem ist. Es ist keine gute Idee, Klassen zu erstellen, die ohne ihre Namespace-Deklarationen kollidieren.
List<T>Insbesondere sollte es als reserviertes Wort behandelt und nicht als Name für Ihre Klassen verwendet werden.
Ebenso sollten einzelne Namespaces innerhalb des Projekts nach eindeutigen Klassennamen streben. Wenn Sie versuchen, herauszufinden, mit welchem Namespace Foo()Sie arbeiten, ist dies ein mentaler Aufwand, der am besten vermieden wird. Anders gesagt: Sie müssen MyCorp.Bar.Foo()und werden MyCorp.Baz.Foo()Ihre Entwickler aus der Ruhe bringen und dies am besten vermeiden.
Wenn nicht anders angegeben, können Sie teilweise Namespaces verwenden, um die Mehrdeutigkeit aufzulösen. Wenn Sie beispielsweise keine der Foo()Klassen umbenennen können, können Sie deren Teil-Namespaces verwenden:
Bar.Foo()
Baz.Foo()
Spezifische Gründe für Ihr aktuelles Projekt:
Sie haben Ihre Frage mit den spezifischen Gründen aktualisiert, die Sie für Ihr aktuelles Projekt angegeben haben. Lassen Sie uns einen Blick auf sie werfen und wirklich den Hasenpfad entlang schweifen.
Es ist umständlich, mit der Maus über den Namen zu fahren, um den vollqualifizierten Typ zu erhalten. Es ist besser, immer den vollständig qualifizierten Typ sichtbar zu haben.
"Schwerfällig?" Ähm, nein. Vielleicht ärgerlich. Das Bewegen einiger Unzen Plastik, um einen Bildschirmzeiger zu verschieben, ist nicht umständlich . Aber ich schweife ab.
Diese Argumentation scheint eher eine Vertuschung zu sein als alles andere. Auf den ersten Blick würde ich vermuten, dass die Klassen in der Anwendung schwach benannt sind und Sie sich auf den Namespace verlassen müssen, um die entsprechende Menge an semantischen Informationen zu erhalten, die den Klassennamen umgeben.
Dies ist keine gültige Rechtfertigung für vollständig qualifizierte Klassennamen. Vielleicht ist es eine gültige Rechtfertigung für die Verwendung von teilweise qualifizierten Klassennamen.
Codeausschnitte per E-Mail haben nicht den vollständigen Namen und sind daher möglicherweise schwer zu verstehen.
Diese (Fortsetzung?) Argumentation untermauert meinen Verdacht, dass Klassen derzeit schlecht benannt sind. Auch hier ist mit Namen schlecht Klasse keine gute Begründung für die Forderung , alles über ein voll qualifizierten Klassennamen zu verwenden. Wenn der Klassenname schwer zu verstehen ist, ist viel mehr falsch, als mit vollständig qualifizierten Klassennamen behoben werden kann.
Wenn Sie den Code außerhalb von Visual Studio anzeigen oder bearbeiten (z. B. Notepad ++), ist es nicht möglich, den vollständig qualifizierten Typnamen abzurufen.
Aus all den Gründen hätte ich beinahe mein Getränk ausgespuckt. Aber ich schweife ab.
Ich frage mich, warum das Team häufig Code außerhalb von Visual Studio bearbeitet oder anzeigt. Und jetzt sehen wir uns eine Rechtfertigung an, die ziemlich orthogonal zu den Namespaces ist, die bereitgestellt werden sollen. Dies ist ein werkzeuggestütztes Argument, während Namespaces dazu dienen, dem Code eine Organisationsstruktur zu geben.
Es hört sich so an, als ob Ihr eigenes Projekt unter schlechten Namenskonventionen leidet, zusammen mit Entwicklern, die nicht die Vorteile nutzen, die die Tools für sie bieten können. Und anstatt diese tatsächlichen Probleme zu lösen, haben sie versucht, ein Pflaster über eines der Symptome zu legen und benötigen vollständig qualifizierte Klassennamen. Ich denke, es ist sicher, dies als einen fehlgeleiteten Ansatz zu kategorisieren.
Angesichts der Tatsache, dass es schlecht benannte Klassen gibt und Sie nicht umgestalten können, ist die richtige Antwort, die Visual Studio-IDE zu ihrem vollen Vorteil zu nutzen. Erwägen Sie möglicherweise, ein Plugin wie das VS PowerTools-Paket hinzuzufügen. Wenn ich mir dann anschaue, AtrociouslyNamedClass()kann ich auf den Klassennamen klicken, F12 drücken und direkt zur Definition der Klasse weitergeleitet werden, um besser zu verstehen, was sie versucht zu tun. Ebenso kann ich Shift-F12 drücken, um alle Stellen im Code zu finden, die gerade benutzt werden müssen AtrociouslyNamedClass().
In Bezug auf die Probleme mit den Außenwerkzeugen ist es am besten, diese einfach zu beenden. Schicken Sie keine Schnipsel per E-Mail hin und her, wenn nicht sofort klar ist, worauf sich der Verweis bezieht. Verwenden Sie keine anderen Tools außerhalb von Visual Studio, da diese Tools nicht über die für Ihr Team erforderlichen Informationen zum Code verfügen. Notepad ++ ist ein großartiges Tool, aber es ist nicht für diese Aufgabe geeignet.
Daher stimme ich Ihrer Einschätzung hinsichtlich der drei spezifischen Begründungen zu, die Ihnen vorgelegt wurden. Ich denke, Ihnen wurde jedoch gesagt: "Wir haben grundlegende Probleme in diesem Projekt, die wir nicht lösen können / wollen, und auf diese Weise haben wir sie" behoben "." Und das spricht offensichtlich für tiefere Probleme innerhalb des Teams, die für Sie als rote Fahnen dienen können.