Ich entwickle ein Framework und einige der Objekte haben wirklich lange Namen. Ich mag das nicht wirklich, aber ich mag auch keine Abkürzungen. Ich versuche, einen kürzeren Namen für "EventModelSocket", im Grunde ein Wrapper um die .Net-Socket-Klasse, die verschiedene Ereignisse implementiert, und Methoden zum Senden von Dateien, Objekten usw. Einige der Objekte haben wirklich lange Namen aufgrund dieser B. "EventModelSocketObjectReceivedEventArgs".
Ich habe alles versucht, von einem Thesaurus über ein Wörterbuch bis hin zu stundenlangem Sitzen.
Wenn Sie auf solche Situationen stoßen, wie können Sie dann am besten etwas benennen?
Drücken Sie etwas davon in den Namensraum.
Zum Beispiel:
%Vor%wird
%Vor%Nun, tun die langen Namen etwas weh?
(bearbeiten) zwei andere Gedanken:
var in C # 3.0 - das spart die halbe Breite Wenn Sie den Typ mehrmals in einer Datei verwenden, sollten Sie einen Typalias berücksichtigen, wenn Sie das stören:
using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;
Vor Jahren, als ich noch in einer Programmierklasse war, zitierte der prof die Statistik, dass ein Code normalerweise 600 Mal gelesen wird, jedes Mal wenn er verändert wurde. Heutzutage würde ich annehmen, dass dies nicht mehr zutrifft, insbesondere in TDD-Umgebungen, in denen viele Refactoring-Prozesse stattfinden. Trotzdem denke ich, dass ein bestimmter Code immer noch viel öfter gelesen wird, als er geschrieben wird. Daher denke ich, dass die Maxime, die wir aus Gründen der Lesbarkeit schreiben sollten, immer noch gültig ist. Die vollständige Form eines Wortes in einem Namen ist lesbarer, da das Gehirn die Umwandlung nicht durchführen muss. Das Verständnis ist schneller und genauer.
Die Tools, die wir heute haben, machen dies mit Autokomplettierung und dergleichen so einfach. Aus diesem Grund verwende ich jetzt vollständige Wörter in Variablennamen, und ich denke, es ist ein guter Weg zu gehen.
Wenn Sie sich so viel Mühe geben müssen, um einen alternativen Namen zu finden, haben Sie bereits den richtigen Namen. Objekt- / Methoden- / Eigenschaftsnamen sollten selbstdokumentierend sein. Wenn sie ihren genauen Zweck nicht beschreiben, werden sie falsch benannt. Es ist nichts falsch mit langen Namen, wenn sie den Zweck dieses Objekts am klarsten verstehen.
In diesem Zeitalter von Intellisense und großen Monitoren gibt es wirklich keine Entschuldigung, um nicht so beschreibend wie möglich in der Benennung zu sein.
Entfernen Sie nicht die Vokale oder so etwas Verrücktes.
Ich bin bei den "Stick mit dem langen Namen" Leute.
Ein Gedanke ist, dass wenn die Namen so peinlich sind, vielleicht ein tiefgründiges Umdenken des Systems notwendig ist.
Ich benutze zum einen den langen Namen. Wenn Sie intellisense eingeben, ist der Name nicht so wichtig, es sei denn, Sie verwenden einen 15-Zoll-Monitor.
Wenn ich den Namen reduzieren müsste, würde ich vielleicht EvtMdlSck verwenden, um die Arbeit kürzer zu machen, aber immer noch verstanden zu haben. Auch wenn das nicht meine Vorliebe ist.
Einige Kritikpunkte an Ihrer Benennung ...
Warum hat Ihre Komponente das Wort "Modell" in ihrem Namen - ist das nicht ein bisschen redundant.
Da Ihre Komponente irgendwie ein Messaging-Hub zu sein scheint, schließen Sie sie ein Nachricht in seinem Namen. Was ist mit MessageSender?
Um Ihr Problem zu lösen, würde ich ein Interface erstellen und ihm einen generischen Namen geben MessageSender und eine Implementierung, wo Sie die Technologie in den Namen wie RandomFailingSocketMessageSender enthalten.
Wenn Sie ein gutes Beispiel dafür bekommen möchten, schauen Sie sich die Java oder .Net Bibliotheken an.
aus Java. Schnittstelle - Klasse / Implementierungen ... Karte - HashMap, LinkedHashMap. Liste - LinkedList
Details bezüglich der verwendeten Technologie oder des verwendeten Frameworks wie zB "Socket" oder vielleicht um ein künstliches Beispiel zu verwenden "MQSeries" sollte nicht Teil des Interface-Namens sein.
MessageSender scheint IMHO den Zweck Ihrer Komponente zusammenzufassen. Es erscheint seltsam, dass Ihr Ding, das "Dateien" und "Ereignisse" sendet, diese beiden beschreibenden Wörter nicht enthält. Die Dinge, die Sie in Ihrer Benennung verwenden, sind überflüssig und IMHO passt nicht zu Ihrer Beschreibung der Komponente.
Im Allgemeinen glaube ich an Klassennamen, die ihre Funktion genau beschreiben, und das ist in Ordnung, lange Namen zu haben. Wenn Sie denken, dass die Namen wirklich lang werden, dann würde ich vorschlagen, ein Konzept zu finden, das Ihrem Programmierer-Team bekannt ist und es abkürzt. Also, wenn "Event Model Sockets" ein Konzept sind, das jeder kennt, dann kürzen Sie sie zu EMS. Wenn Sie ein Paket haben, das sich ausschließlich mit Event Model Sockets befasst, dann kürzen Sie es in allen internen Klassen dieses Pakets zu EMS. Der Schlüssel hier ist, um sicherzustellen, dass der Name vollständig für jeden ist, der nicht mit dem Konzept vertraut und abgekürzt für jeden ist, der ist.
Tags und Links c# naming-conventions