Wenn Sie also eine boolesche Methode schreiben, verwenden Sie bei der Benennung der Rückgabemethode Tempus, wie "hat" oder "war", oder verwenden Sie nur "ist"?
Das Folgende ist eine Java-Methode, die ich kürzlich geschrieben habe, ganz einfach ..
%Vor%In diesem Fall ist "wiederhergestellt" ein Zustand, in dem bereits an dieser Stelle im Code aufgetreten sein könnte. Daher ist grammatisch "was" sinnvoll. Aber macht es auch im Code Sinn, wo die Namenskonvention "is" normalerweise Standard ist?
Ich bevorzuge die Verwendung von IsFoo() unabhängig von der Zeitform, einfach weil es eine gut verstandene Konvention ist, die Nicht-Muttersprachler im Allgemeinen immer noch verstehen. Nicht-Muttersprachler des Englischen werden in der heutigen globalen Dev-Industrie regelmäßig berücksichtigt.
Ich verwende die Zeitform, die der Bedeutung des Wertes entspricht. Andernfalls wird im Wesentlichen Code erstellt, der in eine Richtung liest und sich anders verhält. Schauen wir uns ein Beispiel aus der realen Welt im .Net Framework an: Thread.IsAlive
Diese Eigenschaft wird mit dem Präsens dargestellt. Dies hat die Implikation, dass der Wert sich auf die Gegenwart bezieht und Code wie das Folgende sehr gut lesen lässt %Vor%
Das Problem hier ist, dass die Eigenschaft nicht den aktuellen Zustand des Objekts repräsentiert, das sie als vergangenen Zustand darstellt. Sobald der Wert als true berechnet wurde, kann der fragliche Thread sofort beendet und der Wert ungültig gemacht werden. Daher kann der Wert nur sicher verwendet werden, um den vergangenen Zustand des Threads zu identifizieren, und eine Vergangenheitseigenschaft ist geeigneter. Lassen Sie uns nun die Probe, die ein bisschen anders liest, nochmals besuchen
Sie verhalten sich gleich, aber man liest sehr schlecht, weil es in der Tat schlechten Code darstellt.
Hier ist eine Liste einiger anderer Täter
File.Exists Directory.Exists DriveInfo.IsReady WeakReference.IsAlive Das Präfix isXxx ist eine weit verbreitete Namenskonvention, daher ist es im Allgemeinen die beste Wahl.
Für auftragsabhängige Vorgänge ist wasXxx angemessen. In JDBC kann z. B. beim Abrufen des Werts einer Datenbankspalte Null zurückgegeben werden, wenn das Feld tatsächlich NULL (nicht gesetzt) ist. In diesem Fall bestimmt ein Folgeaufruf zu wasNull , welcher ist, nachdem der tatsächliche Abruf durchgeführt wurde.
Zum Abrufen von Attributeinstellungen ist hasXxx möglicherweise besser geeignet. Es ist eine Grammatikpräferenz, wie in "das Objekt-Flag ist festgelegt" gegenüber "das Objekt hat ein Attribut".
Dann gibt es Fähigkeitstests canXxx . Rufen Sie beispielsweise canWrite auf, um festzustellen, ob eine Datei beschreibbar ist. Namen wie diese können jedoch wahrscheinlich in das Formular isXxx umbenannt werden, z. B. isWritable .
Ich tendiere dazu, ja. Zum Beispiel bei der Fehlerprüfung:
%Vor% Ich bin mir nicht sicher, ob Sie richtig darüber nachdenken. Der Grund, warum man die Recovered -Eigenschaft verwenden würde, liegt darin, dass dies der Zustand ist, in dem sich das Objekt jetzt befindet, und nicht, weil dies der Zustand war, in dem sich das Objekt befand. Möglicherweise gab es einen Prozess in der Vergangenheit (Die Wiederherstellung), die nun abgeschlossen ist, aber die Tatsache, dass wir auf diese Eigenschaft zugreifen, bedeutet nun, dass etwas an diesem abgeschlossenen Prozess den aktuellen Zustand geändert hat und dieser aktuelle Zustand wichtig ist. Für mich "Recovered" erfasst die Natur dieses Staates. Für dieses Beispiel (und die meisten ähnlichen Situationen) würde ich IsRecovered verwenden, um das Prädikat zu benennen, das diese Bedingung angibt. (Dies entspricht auch normalem Englisch: "Dies ist ein wiederhergestelltes Dokument.")
Es ist äußerst selten, dass ich etwas anderes als Gegenwart verwenden würde, um ein Prädikat ( IsDirty , HasCoupon ) oder eine boolsche Funktion ( IsPrime(x) ) in einem Programm zu benennen.
Eine Ausnahme wäre, einen Status anzugeben, der seither geändert wurde und der möglicherweise wiederhergestellt werden muss ( DocumentWindow.WasMaximizedAtLastExit ).
Ich würde normalerweise einen Infinitiv für die Zukunft verwenden ( ToBeCopied anstatt WillBeCopied ), da die besten Pläne der Software manchmal geändert (oder abgebrochen) werden.
Um zu versuchen, die Semantik zu vereinfachen, erkennen Sie, dass es ein paar Szenarien gibt, die die IsXXX-Form diskutabel machen, und einige sehr häufige Szenarien, in denen die IsXXX-Form die einzige nützliche ist.
Unten ist die 'Wahrheitstabelle' für Thread.IsAlive () basierend auf möglichen Zuständen des Threads im Zeitverlauf. Vergiss warum ein Thread Flip-Flop-Zustände haben könnte, wir müssen uns auf die verwendete Sprache konzentrieren.
Hinweis: Ich spreche aus Gründen der Konsistenz über den zukünftigen Status. Zu wissen, ob ein Thread stirbt, ist sehr wahrscheinlich unknowable als Teilmenge von The Halting Problem )
Wenn wir ein Objekt abfragen, indem wir eine Methode aufrufen, gibt es eine allgemeine Annahme: "Ist dieser Thread am Leben, zu der Zeit, als ich fragte ? Für diese Fälle lautet die Antwort in der Spalte" Present " Alles, was uns interessiert und das IsXXX-Formular verwendet, funktioniert gut.
Die Szenarien # 1 (immer am Leben) und # 4 (immer tot) sind am einfachsten und am häufigsten. Die Antwort auf IsAlive() wird zwischen den Anrufen nicht geändert. Der Kampf um die Sprache, der auftritt, ist auf die anderen 6 Fälle zurückzuführen, in denen das Ergebnis des Aufrufs von IsAlive() von abhängt, wenn aufgerufen wird.
Szenarien # 2 (wird sterben) und # 3 (ist gestorben) wechselt von lebendig zu tot.
Die Szenarien # 5 (wird gestartet) und # 6 (hat begonnen) wechselt von "dead" zu "alive".
Für diese vier (2, 3, 5, 6) ist die Antwort auf IsAlive() nicht konstant. Die Frage wird, ob ich mich um den Status "Present", IsAlive() , kümmere, oder bin ich am Zustand "Past / Future" interessiert, WasAlive() und WillBeAlive() ? Sofern Sie die Zukunft nicht vorhersagen können, wird der Aufruf WillBeAlive() für alle außer den spezifischsten Designs bedeutungslos.
Wenn wir uns mit einem Thread-Pool beschäftigen, müssen wir möglicherweise Threads, die sich im Status "dead" befinden, neu starten, um Verbindungsanforderungen zu bedienen, und es spielt keine Rolle, ob sie jemals aktiv waren, nur dass sie momentan tot sind. In diesem Fall möchten wir möglicherweise WasDead() verwenden. Natürlich sollten wir versuchen zu garantieren, dass wir einen Thread nicht neu starten, der gerade neu gestartet wurde, aber das ist ein Designproblem, kein semantisches. Angenommen, dass niemand den Thread neu starten kann, spielt es keine Rolle, ob wir IsAlive() == false oder WasDead() == true verwenden.
Nun zu den letzten beiden Szenarien. Szenario # 7 (war tot, lebt, ist tot) ist praktisch identisch mit # 6 . Weißt du wann es in Zukunft sterben wird? In 10 Sekunden, 10 Minuten, 10 Stunden? Wirst du warten bevor du entscheidest was zu tun ist. Nein, Sie interessieren sich nur für den aktuellen (gegenwärtigen) Staat. Wir reden über die Benennung hier, nicht Multi-Thread-Design.
Szenario # 8 (war am Leben, ist tot, wird am Leben sein), ist praktisch dasselbe wie # 3 . Wenn Sie Threads erneut verwenden, können sie mehrere Male durch den Status "lebend / tot" wechseln. Die Sorge um den Unterschied zwischen # 3 und # 8 geht auf das Halteproblem zurück und kann daher ignoriert werden.
IsAlive() sollte für alle Fälle funktionieren. IsAlive() == false funktioniert (für # 5 und # 6 ) anstatt WasAlive() hinzuzufügen.
Es macht mir nichts aus wasRecovered so sehr. Recovery ist ein Ereignis in der Vergangenheit, das vielleicht passiert ist oder nicht - das zeigt dir, ob es passiert ist oder nicht. Aber wenn Sie es wegen einiger Konsequenz der Wiederherstellung verwenden, würde ich isCached , isValid oder eine andere Beschreibung dessen, was diese Konsequenzen tatsächlich sind, bevorzugen. Nur weil du etwas erholt hast, heißt das nicht automatisch, dass du es seither nicht mehr verloren hast.
Achten Sie immer darauf, dass im Englischen die Verwendung eines Partizips der Vergangenheit als Adjektiv zwischen transitiven und intransitiven Verben (und vielleicht zwischen aktiver und passiver Stimme) mehrdeutig ist. isRecovered könnte bedeuten, dass das Objekt durch etwas anderes wiederhergestellt wurde, oder es könnte bedeuten, dass das Objekt wiederhergestellt wurde . Wenn Ihr Objekt einen Patienten in einem Krankenhaus darstellt, bedeutet "isRecovered", dass der Patient fit und gesund ist oder dass jemand den Patienten aus der Röntgenabteilung zurückgeholt hat? wasRecovered könnte daher für Letzteres besser sein.
Die Einbildung für die Benennung von Methoden besteht darin, dass Sie Informationen über das betreffende Objekt abrufen. Damit es in der Vergangenheitsform benannt wird, müsste es sich um Informationen über einen vorherigen Zustand des Objekts und nicht um seinen aktuellen Status handeln.
Der einzige Grund, warum ich jemals daran denken könnte, die Vergangenheitsform zu verwenden, ist, wenn ich ein zwischengespeichertes Ergebnis von etwas überprüfe, das vorher aufgetreten ist, aber nicht mehr der Fall ist. Für ein künstliches Beispiel, vielleicht den vorherigen Wert nach etwas wie einem swap() -Ruf abrufen. Es könnte bei atomaren Operationen nützlich sein. In der Wildnis allerdings nicht wirklich wahrscheinlich.
Tags und Links language-agnostic naming-conventions