Kürzere Namenskonvention für Typen

Question

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, zu einem Wörterbuch, um stundenlang hier zu sitzen.

Wenn Sie auf solche Situationen stoßen, was ist der beste Weg, etwas zu benennen?

Answer 1

Drücken Sie einige davon in den Namensraum.

Zum Beispiel:

EventModelSocketObjectReceivedEventArgs 

wird

EventModel.Sockets.ReceivedEventArgs 

Answer 2

Nun, tun die langen Namen etwas weh?

(edit) zwei weitere Gedanken:

• Verwendung var in C# 3.0 - das wird

• die halbe Breite sparen, wenn Sie den Typ mehrmals in einer Datei verwenden, eine Art Alias ​​betrachten wenn es ärgerlich Sie:

  using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;

Answer 3

ich für einen Einsatz der lange nam e. 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, könnte ich mit EvtMdlSck nur die Arbeit kürzer machen, aber immer noch verstanden. Auch wenn das nicht meine Vorliebe ist.

Answer 4

Ich würde nur die knappste Benennung vorschlagen, mit, die das Objekt beschreibt. Wenn EventModelSocketObjectReceivedEventArgs das tut, weitermachen. Meine 2 Cent.

Answer 5

Vor Jahren, als ich in einer Programmierklasse war, zitierte der prof die Statistik, dass ein Stück Code in der Regel 600 Mal für jedes einzelne Mal gelesen wird, das es geä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 so einfach mit Autovervollständigung und dergleichen. Aus diesem Grund verwende ich jetzt vollständige Wörter in Variablennamen, und ich denke, es ist ein guter Weg zu gehen.

Answer 6

Wenn Sie so viel Mühe brauchen, 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.

Answer 7

Einige Kritikpunkte auf Ihrer Namensgebung ...

Warum hat Ihr Komponente das Wort „Modell“ in seinem Namen hat - ist das nicht ein bisschen überflüssig.

Da Ihre Komponente scheint ein Messaging-Hub irgendeiner Art zu sein, warum nicht enthalten Nachricht in seinem Namen. Was ist mit MessageSender?

Um Ihr Problem zu lösen, würde ich eine Schnittstelle erstellen und gab ihm einen generischen Namen wie MessageSender und eine Implementierung, wo Sie die Technologie in den Namen wie RandomFailingSocketMessageSender enthalten.

Will man ein gutes Beispiel dafür nimmt einen Blick auf den Java- oder .NET-Bibliotheken ..

von Java erhalten. 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.

Answer 8

Entfernen Sie nicht die Vokale oder etwas so verrückt.

Ich bin mit den "Stick mit dem langen Namen" Menschen.

Ein Gedanke ist, dass, wenn die Namen so peinlich sind, vielleicht ein tiefgründiges Umdenken des Systems notwendig ist.

Answer 9

Im Allgemeinen glaube ich an Klassennamen, die ihre Funktion genau beschreiben, und das ist OK, 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 für jeden vollständig ist, der mit dem Konzept nicht vertraut ist und für jeden abgekürzt wird, der ist.