Findet sonst noch jemand das Benennen von Klassen und Methoden als einen der schwierigsten Teile der Programmierung? [geschlossen]

Ich arbeite an dieser Klasse, die über einen Webdienst Hilfedokumentation von einem Anbieter anfordern soll. Ich versuche , es zu nennen DocumentRetriever, VendorDocRequester, DocGetter, aber sie klingen einfach nicht richtig. Am Ende habe ich eine halbe Stunde lang auf dictionary.com gestöbert und versucht, ein passendes Wort zu finden.

Das Programmieren mit schlechten Namen ist wie ein sehr schlechter Tag am Morgen, der Rest des Tages geht von dort aus bergab. Fühle mich?

Was Sie jetzt tun, ist in Ordnung, und ich empfehle Ihnen dringend, sich an Ihre aktuelle Syntax zu halten:

Kontext + Verb + wie

Ich verwende diese Methode, um Funktionen / Methoden, gespeicherte SQL-Prozesse usw. zu benennen. Wenn Sie diese Syntax einhalten, bleiben Ihre Intellisense- / Codefenster viel ordentlicher. Sie möchten also EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID (). Wenn Sie eine grammatikalisch korrektere Syntax wie GetEmployee () und AddEmployee () verwenden, werden Sie feststellen, dass dies sehr unübersichtlich wird, wenn Sie mehrere Gets in derselben Klasse haben, da nicht verwandte Dinge zusammen gruppiert werden.

Ich vergleiche dies mit dem Benennen von Dateien mit Datumsangaben. Sie möchten sagen, 2009-01-07.log nicht 1-7-2009.log, da die Reihenfolge nach einer Reihe von Dateien völlig unbrauchbar wird.

Eine Lektion, die ich gelernt habe, ist, dass, wenn Sie keinen Namen für eine Klasse finden, fast immer etwas mit dieser Klasse nicht stimmt:

• du brauchst es nicht
• es macht zu viel

Eine gute Namenskonvention sollte die Anzahl möglicher Namen minimieren, die Sie für eine bestimmte Variable, Klasse, Methode oder Funktion verwenden können. Wenn es nur einen möglichen Namen gibt, werden Sie nie Probleme haben, sich daran zu erinnern.

Für Funktionen und für Singleton-Klassen überprüfe ich die Funktion, um festzustellen, ob ihre Grundfunktion darin besteht, eine Art von Dingen in eine andere Art von Dingen umzuwandeln . Ich verwende diesen Begriff sehr locker, aber Sie werden feststellen, dass eine RIESIGE Anzahl von Funktionen, die Sie schreiben, im Wesentlichen etwas in einer Form annehmen und etwas in einer anderen Form produzieren.

In Ihrem Fall klingt es so, als würde Ihre Klasse eine URL in ein Dokument umwandeln . Es ist ein bisschen komisch, es so zu sehen, aber vollkommen richtig, und wenn Sie anfangen, nach diesem Muster zu suchen, werden Sie es überall sehen.

Wenn ich dieses Muster finde, benenne ich immer die Funktion x Fromy .

Da Ihre Funktion eine URL in ein Dokument umwandelt , würde ich sie benennen

DocumentFromUrl

Dieses Muster ist bemerkenswert häufig. Beispielsweise:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

Sie können auch verwenden, UrlToDocumentwenn Sie mit dieser Bestellung besser vertraut sind. Ob Sie x Fromy oder y Tox sagen, ist wahrscheinlich Geschmackssache, aber ich bevorzuge die FromReihenfolge, da auf diese Weise der Anfang des Funktionsnamens bereits angibt, welchen Typ er zurückgibt.

Wählen Sie eine Konvention und halten Sie sich daran. Wenn Sie darauf achten, in Ihren x Fromy -Funktionen dieselben Namen wie Ihre Klassennamen zu verwenden , ist es viel einfacher, sich zu merken, welche Namen Sie verwendet haben. Natürlich funktioniert dieses Muster nicht für alles, aber es funktioniert dort, wo Sie Code schreiben, der als "funktional" angesehen werden kann.

Manchmal gibt es keinen guten Namen für eine Klasse oder Methode, das passiert uns allen. Oft kann jedoch die Unfähigkeit, einen Namen zu finden, ein Hinweis darauf sein, dass etwas mit Ihrem Design nicht stimmt. Hat Ihre Methode zu viele Verantwortlichkeiten? Enthält Ihre Klasse eine zusammenhängende Idee?

Thread 1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

Thread 2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

Hier gibt es keinen Thread.sleep (...).

Ich verbringe auch viel Zeit damit, mir Gedanken über die Namen von Dingen zu machen, denen beim Programmieren ein Name gegeben werden kann. Ich würde sagen, es zahlt sich sehr gut aus. Manchmal, wenn ich feststecke, lasse ich es für eine Weile und während einer Kaffeepause frage ich ein bisschen herum, ob jemand einen guten Vorschlag hat.

Für deine Klasse würde ich vorschlagen VendorHelpDocRequester.

Das Buch Code Complete von Steve Mcconnell enthält ein schönes Kapitel zum Benennen von Variablen / Klassen / Funktionen / ...

Ich denke, das ist ein Nebeneffekt.

Es ist nicht die eigentliche Benennung, die schwierig ist. Was schwierig ist, ist, dass der Prozess des Namensgebens Sie vor die schreckliche Tatsache stellt, dass Sie keine Ahnung haben, was zum Teufel Sie tun.

Ich habe dieses Zitat gestern über den Blog Signal vs. Noise bei 37Signals gehört und bin damit einverstanden:

"In der Informatik gibt es nur zwei schwierige Dinge: die Ungültigmachung des Caches und das Benennen von Dingen." - Phil Karlton

Es ist gut, dass es schwierig ist. Es zwingt Sie, über das Problem nachzudenken und darüber, was die Klasse eigentlich tun soll. Gute Namen können zu gutem Design führen.

Einverstanden. Ich mag es, meine Typnamen und Variablen so beschreibend wie möglich zu halten, ohne zu schrecklich lang zu sein, aber manchmal gibt es nur ein bestimmtes Konzept, für das man kein gutes Wort findet.

In diesem Fall hilft es mir immer, einen Kollegen um Eingabe zu bitten - auch wenn er letztendlich nicht hilft, hilft es mir normalerweise, es zumindest laut zu erklären und meine Räder zum Drehen zu bringen.

Ich habe letzten Monat gerade über Namenskonventionen geschrieben: http://caseysoftware.com/blog/useful-naming-conventions

Das Wesentliche davon:

verbAdjectiveNounStructure - mit Struktur und Adjektiv als optionalen Teilen

Bei Verben halte ich mich an Aktionsverben: Speichern, Löschen, Benachrichtigen, Aktualisieren oder Generieren. Hin und wieder verwende ich "Prozess", aber nur, um speziell auf Warteschlangen oder Arbeitsrückstände zu verweisen.

Für Substantive verwende ich die Klasse oder das Objekt, mit dem / dem interagiert wird. In web2project sind dies häufig Aufgaben oder Projekte. Wenn es sich um Javascript handelt, das mit der Seite interagiert, kann es sich um einen Text oder eine Tabelle handeln. Der Punkt ist, dass der Code das Objekt, mit dem er interagiert, klar beschreibt.

Die Struktur ist optional, da sie für die jeweilige Situation einzigartig ist. Ein Listenbildschirm fordert möglicherweise eine Liste oder ein Array an. Eine der Kernfunktionen, die in der Projektliste für web2project verwendet werden, ist einfach getProjectList. Die zugrunde liegenden Daten werden nicht geändert, sondern nur die Darstellung der Daten.

Die Adjektive sind etwas ganz anderes. Sie werden als Modifikatoren für das Substantiv verwendet. Etwas so Einfaches wie getOpenProjects kann leicht mit einem getProjects und einem switch-Parameter implementiert werden. Dies führt jedoch dazu, dass Methoden generiert werden, die ein gutes Verständnis der zugrunde liegenden Daten und / oder der Struktur des Objekts erfordern ... nicht unbedingt etwas, das Sie möchten ermutigen. Durch explizitere und spezifischere Funktionen können Sie die Implementierung vollständig umschließen und vor dem Code verbergen, der sie verwendet. Ist das nicht einer der Punkte von OO?

Mehr als nur eine Klasse zu benennen, kann das Erstellen einer geeigneten Paketstruktur eine schwierige, aber lohnende Herausforderung sein. Sie müssen in Betracht ziehen, die Belange Ihrer Module und ihre Beziehung zur Vision der Anwendung zu trennen.

Betrachten Sie jetzt das Layout Ihrer App:

• App
  • VendorDocRequester (vom Webdienst lesen und Daten bereitstellen)
  • VendorDocViewer (Verwenden Sie den Anforderer, um Herstellerdokumente bereitzustellen.)

Ich wage zu vermuten, dass in einigen Klassen viel los ist. Wenn Sie dies in einen MVC-orientierten Ansatz umgestalten und kleinen Klassen erlauben, einzelne Aufgaben zu erledigen, könnten Sie am Ende Folgendes haben:

• App
  • VendorDocs
    • Modell
      • Dokument (einfaches Objekt, das Daten enthält)
      • WebServiceConsumer (Umgang mit Kleinigkeiten im Webdienst)
    • Regler
      • DatabaseAdapter (Behandlung der Persistenz mit ORM oder einer anderen Methode)
      • WebServiceAdapter (Verwenden Sie Consumer, um ein Dokument abzurufen und in die Datenbank zu kopieren.)
    • Aussicht
      • HelpViewer (verwenden Sie DBAdapter, um die Dokumentation auszuspucken)

Dann stützen sich Ihre Klassennamen auf den Namespace, um den vollständigen Kontext bereitzustellen. Die Klassen selbst können inhärent mit der Anwendung verknüpft sein, ohne dass dies explizit angegeben werden muss. Klassennamen sind dadurch einfacher und leichter zu definieren!

Ein weiterer sehr wichtiger Vorschlag: Bitte tun Sie sich selbst einen Gefallen und holen Sie sich eine Kopie von Head First Design Patterns. Es ist ein fantastisches, einfach zu lesendes Buch, mit dem Sie Ihre Anwendung organisieren und besseren Code schreiben können. Das Erkennen von Entwurfsmustern hilft Ihnen zu verstehen, dass viele der aufgetretenen Probleme bereits gelöst wurden, und Sie können die Lösungen in Ihren Code integrieren.

Leo Brodie schrieb in seinem Buch "Thinking Forth", dass die schwierigste Aufgabe für einen Programmierer darin bestehe, die Dinge gut zu benennen, und er erklärte, dass das wichtigste Programmierwerkzeug ein Thesaurus sei.

Versuchen Sie es mit dem Thesaurus unter http://thesaurus.reference.com/ .

Verwenden Sie darüber hinaus NIEMALS die ungarische Notation, vermeiden Sie Abkürzungen und seien Sie konsistent.

Die besten Wünsche.

Kurz gesagt:
Ich stimme zu, dass gute Namen wichtig sind, aber ich denke nicht, dass Sie sie finden müssen, bevor Sie sie um jeden Preis implementieren.

Natürlich ist es besser, von Anfang an einen guten Namen zu haben. Wenn Sie jedoch nicht in zwei Minuten eine finden können, kostet das spätere Umbenennen weniger Zeit und ist aus Sicht der Produktivität die richtige Wahl.

Lang: Im
Allgemeinen lohnt es sich oft nicht, vor der Implementierung zu lange über einen Namen nachzudenken. Wenn Sie Ihre Klasse implementieren, indem Sie sie "Foo" oder "Dsnfdkgx" nennen, sehen Sie während der Implementierung, wie Sie sie hätten benennen sollen.

Insbesondere bei Java + Eclipse ist das Umbenennen von Dingen überhaupt kein Problem, da alle Referenzen in allen Klassen sorgfältig behandelt werden, Sie vor Namenskollisionen gewarnt werden usw. Und solange sich die Klasse noch nicht im Versionskontroll-Repository befindet, tue ich das nicht. Ich glaube nicht, dass etwas falsch ist, wenn man es 5 Mal umbenennt.

Grundsätzlich geht es darum, wie Sie über Refactoring denken. Persönlich mag ich es, obwohl es meine Teamkollegen manchmal nervt, weil sie daran glauben, niemals ein laufendes System zu berühren . Und von allem, was Sie umgestalten können, ist das Ändern von Namen eines der harmlosesten Dinge, die Sie tun können.

Warum nicht HelpDocumentServiceClient als eine Art Bissen oder HelpDocumentClient ... es spielt keine Rolle, ob es sich um einen Anbieter handelt, sondern um einen Client für einen Webservice, der sich mit Hilfedokumenten befasst.

Und ja, das Benennen ist schwer.

Es gibt nur einen vernünftigen Namen für diese Klasse:

HelpRequest

Lassen Sie sich von den Implementierungsdetails nicht von der Bedeutung ablenken.

Investieren Sie in ein gutes Refactoring-Tool!

Ich halte mich an die Grundlagen: VerbNoun (Argumente). Beispiele: GetDoc (docID).

Es besteht kein Grund zur Fantasie. In einem Jahr wird es leicht zu verstehen sein, ob Sie es sind oder jemand anderes.

Für mich ist es egal, wie lange ein Methoden- oder Klassenname so lang ist, wie er beschreibend ist und in der richtigen Bibliothek. Die Zeiten, in denen Sie sich daran erinnern sollten, wo sich die einzelnen Teile der API befinden, sind lange vorbei.

Intelisense gibt es für alle wichtigen Sprachen. Wenn ich eine API eines Drittanbieters verwende, verwende ich daher lieber deren Intelisense für die Dokumentation als die 'tatsächliche' Dokumentation.

In diesem Sinne kann ich einen Methodennamen wie erstellen

StevesPostOnMethodNamesBeingLongOrShort

Lang - aber na und. Wer verwendet heutzutage keine 24-Zoll-Bildschirme!

Ich muss zustimmen, dass das Benennen eine Kunst ist. Es wird ein wenig einfacher, wenn Ihre Klasse einem bestimmten "Desigh-Muster" folgt (Fabrik usw.).

Dies ist einer der Gründe für einen Codierungsstandard. Wenn Sie einen Standard haben, können Sie bei Bedarf Namen finden. Es hilft Ihnen, Ihren Geist für andere interessantere Dinge zu befreien! (-:

Ich würde empfehlen, das entsprechende Kapitel von Steve McConnells Code Complete ( Amazon-Link ) zu lesen, das verschiedene Regeln enthält, um die Lesbarkeit und sogar Wartbarkeit zu verbessern.

HTH

Prost,

rauben

Nein, das Debuggen ist das Schwierigste für mich! :-)

DocumentFetcher? Ohne Kontext ist es schwer zu sagen.

Es kann hilfreich sein, sich wie ein Mathematiker zu verhalten und unterwegs ein Lexikon für Ihre Domain auszuleihen / zu erfinden: Entscheiden Sie sich für kurze, einfache Wörter, die das Konzept vorschlagen, ohne es jedes Mal zu formulieren . Zu oft sehe ich lange lateinische Phrasen, die in Akronyme umgewandelt werden, sodass Sie ohnehin ein Wörterbuch für die Akronyme benötigen .

Die Sprache, die Sie zur Beschreibung des Problems verwenden, ist die Sprache, die Sie für die Variablen, Methoden, Objekte, Klassen usw. verwenden sollten. Nomen stimmen lose mit Objekten und Verben mit Methoden überein. Wenn Ihnen Wörter fehlen, um das Problem zu beschreiben, fehlt Ihnen auch ein umfassendes Verständnis (Spezifikation) des Problems.

Wenn Sie nur zwischen einer Reihe von Namen wählen, sollte dies von den Konventionen abhängen, die Sie zum Erstellen des Systems verwenden. Wenn Sie an einen neuen Ort gekommen sind, der durch frühere Konventionen aufgedeckt wurde, lohnt es sich immer, einige Anstrengungen zu unternehmen, um sie (richtig, konsequent) zu erweitern, um diesen neuen Fall abzudecken.

Wenn Sie Zweifel haben, schlafen Sie darauf und wählen Sie am nächsten Morgen den ersten offensichtlichen Namen :-)

Wenn Sie eines Tages aufwachen und feststellen, dass Sie sich geirrt haben, ändern Sie es sofort.

Paul.

Übrigens: Document.fetch () ist ziemlich offensichtlich.

Ich finde, ich habe die meisten Probleme mit lokalen Variablen. Zum Beispiel möchte ich ein Objekt vom Typ DocGetter erstellen. Ich weiß also, dass es ein DocGetter ist. Warum muss ich ihm einen anderen Namen geben? Normalerweise gebe ich ihm einen Namen wie dg (für DocGetter) oder temp oder etwas ähnlich Unbeschreibliches.

Vergessen Sie nicht, dass Designmuster (nicht nur die GoF-Muster) eine gute Möglichkeit sind, ein gemeinsames Vokabular bereitzustellen. Ihre Namen sollten immer dann verwendet werden, wenn sie der Situation entsprechen. Dies hilft sogar Neulingen, die mit der Nomenklatur vertraut sind, die Architektur schnell zu verstehen. Soll sich diese Klasse, an der Sie arbeiten, wie ein Stellvertreter oder sogar wie eine Fassade verhalten?

Sollte die Herstellerdokumentation nicht das Objekt sein? Ich meine, dass man greifbar ist und nicht nur als Anthropomorphisierung eines Teils Ihres Programms. Möglicherweise haben Sie eine VendorDocumentationKlasse mit einem Konstruktor, der die Informationen abruft. Ich denke, wenn ein Klassenname ein Verb enthält, ist oft etwas schiefgegangen.

Ich fühle dich definitiv. Und ich fühle deinen Schmerz. Jeder Name, an den ich denke, scheint mir nur Müll zu sein. Es scheint alles so allgemein zu sein und ich möchte irgendwann lernen, wie ich meinen Namen ein bisschen Flair und Kreativität verleihen kann, damit sie wirklich das widerspiegeln, was sie beschreiben.

Ein Vorschlag, den ich habe, ist, einen Thesaurus zu konsultieren. Word hat ein gutes Wort, ebenso wie Mac OS X. Das kann mir wirklich helfen, meinen Kopf aus den Wolken zu holen, und gibt mir einen guten Ausgangspunkt sowie Inspiration.

Wenn sich der Name einem Laienprogrammierer erklären würde, müsste er wahrscheinlich nicht geändert werden.