Frage Verwenden Sie Tempus beim Benennen von Methoden des booleschen Rückgabetyps?


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 ..

boolean recovered = false;

public boolean wasRecovered()
{
     return recovered;
}

In diesem Fall ist "wiederhergestellt" ein Zustand, der möglicherweise vorhanden ist oder nicht bereits An dieser Stelle im Code aufgetreten ist, so grammatikalisch "war" macht Sinn. Aber macht es auch im Code Sinn, wo die Namenskonvention "ist" normalerweise Standard ist?


8
2017-09-08 15:40


Ursprung


Antworten:


Ich bevorzuge es zu benutzen IsFoo()unabhängig von der Zeitform, einfach weil es eine gut verstandene Konvention ist, die Nicht-Muttersprachler immer noch verstehen werden. Nicht-Muttersprachler des Englischen werden in der heutigen globalen Dev-Industrie regelmäßig berücksichtigt.


7
2017-09-08 15:42



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 in der Gegenwart präsentiert. Dies hat die Implikation, dass sich der Wert auf die Gegenwart bezieht und Code wie das Folgende sehr gut lesen lässt

if (thread.IsAlive ) {
  // Code that depends on the thread being alive
  ...

Das Problem hierbei ist, dass die Eigenschaft nicht den aktuellen Zustand des Objekts repräsentiert, das sie als vergangenen Zustand darstellt. Sobald der Wert berechnet wird trueDer betreffende Thread kann den Wert sofort beenden und ungültig machen. Daher kann der Wert nur verwendet werden, um den vergangenen Zustand des Threads zu identifizieren, und eine Vergangenheitseigenschaft ist geeigneter. Lassen Sie uns jetzt die Probe, die ein bisschen anders liest, noch einmal besuchen

if ( thread.WasAlive ) {
  // Code that depends on the thread being alive
  ...

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

4
2017-09-08 15:51



Das isXxx Präfix ist eine weit verbreitete Namenskonvention, daher ist es im Allgemeinen die beste Wahl.

Für auftragsabhängige Vorgänge wasXxx Ist 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 ein Folgeanruf an wasNull bestimmt, was es ist nach das tatsächliche Abrufen wurde durchgeführt.

Zum Abrufen von Attributeinstellungen hasXxx könnte passender sein. Es ist eine Grammatikpräferenz, wie in der "Objektfahne" ist Setzen Sie "versus" auf das Objekt hat ein Attribut ".

Dann gibt es Fähigkeitstests canXxx. Zum Beispiel, anzurufen canWrite um zu sehen, ob eine Datei beschreibbar ist. Aber Namen wie diese können wahrscheinlich in die umbenannt werden isXxx Form, wie z isWritable.


2
2017-09-08 16:24



Ich tendiere dazu, ja. Zum Beispiel bei der Fehlerprüfung:

$errors = false;
public function hasErrors()
{
  return $this->errors;
}

1
2017-09-08 15:45



Ich bin mir nicht sicher, ob Sie richtig darüber nachdenken. Der Grund, warum man das benutzen würde Recovered Eigenschaft ist, weil das der Zustand ist, in dem sich das Objekt befindet jetztNicht, weil das der Zustand war, in dem sich das Objekt befand. Möglicherweise gab es einen Prozess in der Vergangenheit (Die Wiederherstellung), der jetzt abgeschlossen ist, aber die Tatsache, dass wir auf diese Eigenschaft zugreifen, bedeutet nun, dass etwas an dieser abgeschlossen ist Prozess, der den aktuellen Zustand veränderte und dieser aktuelle Zustand ist wichtig. Für mich "Recovered" erfasst die Natur dieses Staates. Für dieses Beispiel (und die meisten ähnlichen Situationen) würde ich verwenden IsRecoveredum das Prädikat zu benennen, das diese Bedingung angibt. (Dies entspricht auch normalem Englisch: "Dies ist ein wiederhergestelltes Dokument.")

Es ist extrem selten, dass ich etwas anderes als Gegenwart verwenden würde, um ein Prädikat zu nennen (IsDirty, HasCoupon) oder boolesche Funktion (IsPrime(x)) in einem Programm.

Eine Ausnahme wäre die Angabe eines Status, der seither geändert wurde und ggf. wiederhergestellt werden muss (DocumentWindow.WasMaximizedAtLastExit).

Ich würde normalerweise einen Infinitiv für die Zukunft verwenden (ToBeCopied eher, als WillBeCopied), da die besten Pläne der Software manchmal geändert (oder abgebrochen) werden.


1
2017-09-08 18:31



Es hängt davon ab, ob Sie sich um den vergangenen oder zukünftigen Zustand der Immobilie kümmern.

Um zu versuchen, die Semantik zu vereinfachen, stellen Sie fest, 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.

Im Folgenden ist die "Wahrheitstabelle" für Thread.IsAlive () basierend auf möglichen Zuständen des Threads im Zeitverlauf. Vergessen Warum Ein Thread könnte Flip-Flop-Zustände haben, wir müssen uns auf die verwendete Sprache konzentrieren.

Szenarien möglicher Thread-Zustände im Zeitverlauf:

    Past        Present     Future  
    =====       =======     =======  
 1. alive       alive       alive  
 2. alive       alive       dead  
 3. alive       dead        dead  
 4. dead        dead        dead
 5. dead        dead        alive
 6. dead        alive       alive
 7. dead        alive       dead
 8. alive       dead        alive

Hinweis: Ich spreche aus Gründen der Konsistenz über den Status "Zukunft". Zu wissen, ob ein Thread stirbt, ist sehr wahrscheinlich unerkennbar als eine Untermenge von Das Halteproblem)

Wenn wir ein Objekt durch Aufruf einer Methode abfragen, gibt es eine allgemeine Annahme: "Ist dieser Thread am Leben, Zu der Zeit fragte ich? Für diese Fälle ist die Antwort in der "Present" -Spalte alles, was uns interessiert und die Verwendung des IsXXX-Formulars funktioniert gut.

Szenarien # 1(immer am Leben) und # 4(immer tot) sind die einfachsten und am häufigsten. Die Antwort auf IsAlive() wird zwischen den Anrufen nicht geändert. Der Kampf um die Sprache, der aufkommt, ist auf die anderen 6 Fälle zurückzuführen, in denen das Ergebnis des Aufrufs war IsAlive() kommt drauf an wann es wird genannt.

Szenarien # 2(wird sterben) und #3(ist gestorben) Übergänge von lebendig zu tot.
Szenarien # 5(wird anfangen) und # 6(hat begonnen) Übergänge von tot zu lebendig.

Für diese vier (2, 3, 5, 6) die Antwort auf IsAlive() ist nicht konstant. Die Frage wird, interessiere ich mich für den gegenwärtigen Zustand, IsAlive()oder interessiere mich für den Zustand Vergangenheit / Zukunft, WasAlive() und WillBeAlive()? Wenn Sie nicht die Zukunft vorhersagen können, die WillBeAlive() Anruf wird 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 "tot" befinden, neu starten, um Verbindungsanforderungen zu bedienen, und es spielt keine Rolle, ob sie jemals am Leben waren, nur dass sie gerade tot sind. In diesem Fall möchten wir vielleicht tatsächlich verwenden WasDead(). 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 ihn verwenden IsAlive() == falseoder WasDead() == true.

Jetzt zu den letzten beiden Szenarien. Szenario # 7(war tot, lebt, wird tot sein) ist praktisch dasselbe # 6. Wissen Sie wann in der Zukunft wird es sterben? 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 sprechen hier über Namen, nicht Multi-Thread-Design.

Szenario # 8(war am Leben, ist tot, wird am Leben sein), ist praktisch das gleiche wie #3. Wenn Sie Threads erneut verwenden, können sie mehrere Male durch den Status "lebend / tot" wechseln. Sich über den Unterschied zwischen #3 und # 8 geht auf das Halting-Problem zurück und kann so ignoriert werden.

IsAlive() sollte für alle Fälle funktionieren. IsAlive() == false funktioniert für # 5 und # 6) anstatt hinzuzufügen WasAlive().


1
2017-09-08 19:53



Es macht mir nichts aus wasRecovered so viel. 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 Folgen der Wiederherstellung verwenden, würde ich bevorzugen isCached, isValidoder eine andere Beschreibung dessen, was diese Konsequenzen tatsächlich sind. Nur weil du etwas erholt hast bedeutet das nicht, dass du es seither nicht wieder 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 das Objekt bedeuten ist gewesen durch etwas anderes wiederhergestellt, oder es könnte das Objekt bedeuten hat sich erholt. 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.


1
2017-09-08 16:03



Die Einbildung für die Methodenbenennung besteht darin, dass Sie Informationen über das betreffende Objekt abrufen. Damit es in der Vergangenheitsform benannt wird, müsste es Informationen über eine sein vorheriger Status des Objekts, anstatt seinen aktuellen Zustand.

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 a zurückholen swap() Anruf. Es könnte bei atomaren Operationen nützlich sein. Nicht wirklich wahrscheinlich in der Wildnis.


0
2017-09-08 15:45