it-swarm.com.de

Der Entwickler besteht darauf, dass Anweisungen keine negierten Bedingungen haben sollten und immer einen else-Block haben sollten

Ich habe einen Bekannten, einen erfahreneren Entwickler als ich. Wir sprachen über Programmierpraktiken und ich war überrascht von seiner Herangehensweise an If-Aussagen. Er besteht auf einigen Praktiken in Bezug auf Aussagen, die ich ziemlich seltsam finde.

Erstens, auf eine if-Anweisung sollte eine else-Anweisung folgen, unabhängig davon, ob etwas darin enthalten ist oder nicht. Was dazu führt, dass Code so aussieht:

if(condition) 
{
    doStuff();
    return whatever;
}
else
{
}

Zweitens, es ist besser, auf wahre Werte zu testen, als auf falsche. Das bedeutet, dass es besser ist, eine 'doorClosed'-Variable anstelle einer'! DoorOpened'-Variablen zu testen

Sein Argument ist, dass es klarer macht, was der Code tut.

Das verwirrt mich ziemlich, da eine Kombination dieser beiden Regeln dazu führen kann, dass er diese Art von Code schreibt, wenn er etwas tun möchte, wenn die Bedingung nicht erfüllt ist.

if(condition)
{
}
else
{
    doStuff();
    return whatever;
}

Mein Gefühl dabei ist, dass es in der Tat sehr hässlich ist und/oder dass die Qualitätsverbesserung, falls vorhanden, vernachlässigbar ist. Aber als Junior neige ich dazu, an meinem Instinkt zu zweifeln.

Meine Fragen sind also: Ist es eine gute/schlechte/"egal" -Praxis? Ist es übliche Praxis?

175
Patsuan

Expliziter else Block

Die erste Regel verschmutzt nur den Code und macht ihn weder lesbarer noch weniger fehleranfällig. Das Ziel Ihres Kollegen - ich würde annehmen - ist es, explizit zu sein, indem gezeigt wird, dass der Entwickler sich voll und ganz bewusst war, dass die Bedingung möglicherweise false ergibt. Obwohl es gut ist, explizit zu sein, sollte eine solche explizite Aussage nicht drei zusätzliche Codezeilen kosten .

Ich erwähne nicht einmal die Tatsache, dass auf eine if -Anweisung nicht unbedingt entweder ein else oder nichts folgt: Es könnten auch ein oder mehrere Elifs folgen.

Das Vorhandensein der Anweisung return macht die Sache noch schlimmer. Selbst wenn Sie tatsächlich Code hätten, der im Block else ausgeführt werden könnte, wäre es besser, dies folgendermaßen zu tun:

if (something)
{
    doStuff();
    return whatever;
}

doOtherThings();
return somethingElse;

Dadurch benötigt der Code zwei Zeilen weniger und hebt den Block else auf. Guard-Klauseln dreht sich alles darum.

Beachten Sie jedoch, dass die Technik Ihres Kollegen ein sehr unangenehmes Muster gestapelter bedingter Blöcke ohne Leerzeichen teilweise lösen kann:

if (something)
{
}
if (other)
{
}
else
{
}

Im vorherigen Code macht es das Fehlen eines vernünftigen Zeilenumbruchs nach dem ersten if -Block sehr leicht, den Code falsch zu interpretieren. Während die Regel Ihres Kollegen es schwieriger machen würde, den Code falsch zu lesen, wäre eine einfachere Lösung, einfach eine neue Zeile hinzuzufügen.

Test für true, nicht für false

Die zweite Regel mag sinnvoll sein, aber nicht in der aktuellen Form.

Es ist nicht falsch, dass das Testen auf eine geschlossene Tür intuitiver ist als das Testen auf eine nicht geöffnete Tür . Negationen und insbesondere verschachtelte Negationen sind normalerweise schwer zu verstehen:

if (!this.IsMaster || (!this.Ready && !this.CanWrite))

Um dies zu lösen, erstellen Sie , anstatt leere Blöcke hinzuzufügen, gegebenenfalls zusätzliche Eigenschaften oder lokale Variablen .

Die obige Bedingung könnte ziemlich leicht lesbar gemacht werden:

if (this.IsSlave || (this.Synchronizing && this.ReadOnly))
189

In Bezug auf die erste Regel ist dies ein Beispiel für nutzloses Tippen. Die Eingabe dauert nicht nur länger, sondern führt auch bei jedem, der den Code liest, zu großer Verwirrung. Wenn der Code nicht benötigt wird, schreiben Sie ihn nicht. Dies würde sogar dazu führen, dass in Ihrem Fall kein else ausgefüllt ist, da der Code aus dem Block if zurückkehrt:

if(condition) 
{
    doStuff();
    return whatever;
}

doSomethingElse(); // no else needed
return somethingelse;

In Bezug auf den zweiten Punkt ist es gut, boolesche Namen zu vermeiden, die ein Negativ enthalten:

bool doorNotOpen = false; // a double negative is hard to reason
bool doorClosed = false; // this is much clearer

Wenn Sie dies jedoch dahingehend erweitern, dass Sie nicht erneut auf ein Negativ testen, führt dies, wie Sie hervorheben, zu einer nutzloseren Eingabe. Folgendes ist weitaus klarer als ein leerer if Block:

if(!condition)
{
    doStuff();
    return whatever;
}
62
David Arno

1. Ein Argument für leere else Anweisungen.

Ich benutze (und argumentiere) oft etwas, das diesem ersten Konstrukt ähnelt, ein leeres anderes. Es signalisiert den Lesern des Codes (sowohl menschliche als auch automatisierte Analysewerkzeuge), dass der Programmierer einige Überlegungen angestellt hat. Fehlende else -Anweisungen, die vorhanden sein sollten, haben Menschen getötet, Fahrzeuge abgestürzt und Millionen von Dollar gekostet. MISRA-C schreibt beispielsweise mindestens einen Kommentar vor, der besagt, dass das fehlende Finale sonst in einer if (condition_1) {do_this;} else if (condition_2) {do_that;} ... else if (condition_n) {do_something_else;} - Sequenz beabsichtigt ist. Andere hohe Zuverlässigkeitsstandards gehen noch weiter: Mit wenigen Ausnahmen sind fehlende else-Aussagen verboten.

Eine Ausnahme ist ein einfacher Kommentar, ähnlich wie /* Else not required */. Dies signalisiert die gleiche Absicht wie die drei leeren Zeilen sonst. Eine weitere Ausnahme, bei der dieses leere andere nicht benötigt wird, besteht darin, dass es sowohl für die Leser des Codes als auch für automatisierte Analysetools offensichtlich ist, dass das leere andere überflüssig ist. Beispiel: if (condition) { do_stuff; return; } Ebenso wird bei throw something Oder goto some_label Kein leeres else benötigt.1 anstelle von return.

2. Ein Argument für den Vorzug von if (condition) gegenüber if (!condition).

Dies ist ein Gegenstand menschlicher Faktoren. Komplexe boolesche Logik stolpert über viele Menschen. Selbst ein erfahrener Programmierer muss über if (!(complex || (boolean && condition))) do_that; else do_this; nachdenken. Schreiben Sie dies mindestens als if (complex || (boolean && condition)) do_this; else do_that; um.

3. Dies bedeutet nicht, dass man leere then Anweisungen bevorzugen sollte.

Der zweite Abschnitt sagt "lieber" als "du sollst". Es ist eher eine Richtlinie als eine Regel. Der Grund für diese Richtlinie, positive if Bedingungen zu bevorzugen, ist, dass der Code klar und offensichtlich sein sollte. Eine leere then-Klausel (z. B. if (condition) ; else do_something;) verletzt dies. Es handelt sich um eine verschleierte Programmierung, die selbst die erfahrensten Programmierer veranlasst, die Bedingung if in ihrer negierten Form zu sichern und erneut zu lesen. Schreiben Sie es also zunächst in der negierten Form und lassen Sie die else-Anweisung weg (oder haben Sie ein leeres else oder einen entsprechenden Kommentar, wenn Sie dazu aufgefordert werden).



1Ich habe geschrieben, dass dann Klauseln, die mit return, throw oder goto enden, kein leeres else erfordern. Es ist offensichtlich, dass die else-Klausel nicht benötigt wird. Aber was ist mit goto? Abgesehen davon verbieten sicherheitskritische Programmierregeln manchmal eine vorzeitige Rückgabe und fast immer das Auslösen von Ausnahmen. Sie erlauben jedoch goto in einer eingeschränkten Form (z. B. goto cleanup1;). Diese eingeschränkte Verwendung von goto ist an einigen Stellen die bevorzugte Vorgehensweise. Der Linux-Kernel zum Beispiel ist voll von solchen goto -Anweisungen.

45
David Hammen

In sehr seltenen Fällen verwende ich einen leeren else-Zweig (und manchmal einen leeren if-Zweig): Wenn es offensichtlich ist, dass sowohl der if- als auch der else-Teil irgendwie behandelt werden sollten, aber aus einem nicht trivialen Grund kann der Fall von behandelt werden nichts tun. Und deshalb würde jeder, der den Code mit der erforderlichen Aktion else liest, sofort vermuten, dass etwas fehlt, und seine Zeit verschwenden.

if (condition) {
    // No action needed because ...
} else {
    do_else_action()
}

if (condition) {
    do_if_action()
} else {
    // No action needed because ...
}

Aber nicht:

if (condition) {
    do_if_action()
} else {
    // I was told that an if always should have an else ...
}
31
gnasher729

Wenn alles andere gleich ist, bevorzugen Sie die Kürze.

Was Sie nicht schreiben, muss niemand lesen und verstehen.

Obwohl es nützlich sein kann, explizit zu sein, ist dies nur dann der Fall, wenn ohne übermäßige Ausführlichkeit deutlich wird, dass das, was Sie geschrieben haben, wirklich das ist, was Sie schreiben wollten.


Vermeiden Sie also leere Zweige, sie sind nicht nur nutzlos, sondern auch ungewöhnlich und führen zu Verwirrung.

Vermeiden Sie es auch, einen else-Zweig zu schreiben, wenn Sie den if-Zweig direkt verlassen.

Eine nützliche Anwendung von explicitness wäre das Einfügen eines Kommentars, wenn Sie durch Switch-Cases // FALLTHRU Fallen, und das Verwenden eines Kommentars oder eines leeren Blocks, in dem Sie eine leere Anweisung for(a;b;c) /**/; benötigen.

22
Deduplicator

Meines Wissens nach gibt es keine feste Regel für positive oder negative Bedingungen für eine IF-Anweisung. Ich persönlich bevorzuge Codierung für einen positiven Fall anstelle eines negativen, wo zutreffend. Ich werde dies jedoch mit Sicherheit nicht tun, wenn es mich dazu bringt, einen leeren IF-Block zu erstellen, gefolgt von einem ELSE voller Logik. Wenn eine solche Situation eintrat, würde es ungefähr 3 Sekunden dauern, bis sie wieder auf einen positiven Fall getestet wurde.

Was ich an Ihren Beispielen wirklich nicht mag, ist der völlig unnötige vertikale Raum, den das leere ELSE einnimmt. Es gibt einfach keinen Grund, dies zu tun. Es fügt der Logik nichts hinzu, es hilft nicht zu dokumentieren, was der Code tut, und es erhöht überhaupt nicht die Lesbarkeit. In der Tat würde ich argumentieren, dass der hinzugefügte vertikale Raum möglicherweise abnehmen Lesbarkeit könnte.

6
Langecrew

Expliziter else Block

Ich bin damit nicht einverstanden, da eine pauschale Anweisung alle if Anweisungen abdeckt, aber es gibt Zeiten, in denen das Hinzufügen eines else Blocks aus Gewohnheit eine gute Sache ist.

Eine if -Anweisung deckt meines Erachtens tatsächlich zwei unterschiedliche Funktionen ab.

Wenn wir etwas tun sollen, tun Sie es hier.

Solche Sachen brauchen offensichtlich nicht einen else Teil.

    if (customer.hasCataracts()) {
        appointmentSuggestions.add(new CataractAppointment(customer));
    }
    if (customer.isDiabetic()) {
        customer.assignNurse(DiabeticNurses.pickBestFor(customer));
    }

und in einigen Fällen kann das Bestehen auf dem Hinzufügen eines else irreführen.

    if (k > n) {
        return BigInteger.ZERO;
    }
    if (k <= 0 || k == n) {
        return BigInteger.ONE;
    }

ist nicht das gleiche wie

    if (k > n) {
        return BigInteger.ZERO;
    } else {
        if (k <= 0 || k == n) {
            return BigInteger.ONE;
        }
    }

obwohl es funktional gleich ist. Wenn Sie das erste if mit einem leeren else schreiben, gelangen Sie möglicherweise zum zweiten Ergebnis, das unnötig hässlich ist.

Wenn wir nach einem bestimmten Status suchen, ist es oft eine gute Idee, ein leeres else hinzuzufügen, um Sie daran zu erinnern, diese Eventualität abzudecken.

        // Count wins/losses.
        if (doors[firstChoice] == Prize.Car) {
            // We would have won without switching!
            winWhenNotSwitched += 1;
        } else {
            // We win if we switched to the car!
            if (doors[secondChoice] == Prize.Car) {
                // We picked right!
                winWhenSwitched += 1;
            } else {
                // Bad choice.
                lost += 1;
            }
        }

Denken Sie daran, dass diese Regeln gelten nur wenn Sie neuen Code schreiben. IMHO Die leeren else -Klauseln sollten vor dem Einchecken entfernt werden.


Test für true, nicht für false

Auch dies ist ein guter Rat auf allgemeiner Ebene, aber in vielen Fällen macht dies Code unnötig komplex und weniger lesbar.

Obwohl Code wie

    if(!customer.canBuyAlcohol()) {
        // ...
    }

erschüttert den Leser, macht es aber

    if(customer.canBuyAlcohol()) {
        // Do nothing.
    } else {
        // ...
    }

ist mindestens genauso schlimm, wenn nicht schlimmer.

Ich habe vor vielen Jahren in BCPL codiert und in dieser Sprache gibt es eine IF -Klausel nd eine UNLESS -Klausel, damit Sie viel besser lesen können als:

    unless(customer.canBuyAlcohol()) {
        // ...
    }

das ist deutlich besser, aber immer noch nicht perfekt.


Mein persönlicher Prozess

Wenn ich neuen Code schreibe, füge ich einer else - Anweisung häufig einen leeren if - Block hinzu, um mich daran zu erinnern, dass ich diese Möglichkeit noch nicht behandelt habe. Dies hilft mir, die DFS -Falle zu umgehen, und stellt sicher, dass ich beim Überprüfen des Codes bemerke, dass noch mehr zu tun ist. Normalerweise füge ich jedoch einen TODO Kommentar hinzu, um den Überblick zu behalten.

  if (returnVal == JFileChooser.APPROVE_OPTION) {
    handleFileChosen();
  } else {
    // TODO: Handle case where they pressed Cancel.
  }

Ich finde, dass ich else im Allgemeinen selten in meinem Code verwende, da dies häufig auf einen Codegeruch hinweist.

5
OldCurmudgeon

Für den ersten Punkt habe ich eine Sprache verwendet, die die Verwendung von IF-Anweisungen auf diese Weise erzwang (in Opal die Sprache hinter einem Mainframe-Bildschirmschaber zum Anbringen eines GUI-Frontends für Mainframe-Systeme) und nur eine Zeile für die IF und das andere. Es war keine angenehme Erfahrung!

Ich würde erwarten, dass jeder Compiler solche zusätzlichen ELSE-Klauseln optimiert. Für Live-Code wird jedoch nichts hinzugefügt (in der Entwicklung kann dies ein nützlicher Marker für weiteren Code sein).

Eine Zeit, in der ich so etwas wie diese zusätzlichen Klauseln verwende, ist die Verwendung der CASE/WHEN-Typverarbeitung. Ich füge immer eine Standardklausel hinzu, auch wenn sie leer ist. Dies ist eine langfristige Gewohnheit von Sprachen, die fehlerhaft sind, wenn eine solche Klausel nicht verwendet wird, und erzwingt einen Gedanken darüber, ob die Dinge wirklich einfach durchfallen sollten.

Vor langer Zeit wurde die Praxis des Mainframes (z. B. PL/1 und COBOL) akzeptiert, dass negative Prüfungen weniger effizient waren. Dies könnte den zweiten Punkt erklären, obwohl es heutzutage massiv wichtigere Effizienzeinsparungen gibt, die als Mikrooptimierungen ignoriert werden.

Negative Logik ist in der Regel weniger lesbar, wenn auch nicht so sehr bei einer so einfachen IF-Anweisung.

1
Kickstart

Ich würde den Stand der meisten Antworten unterstützen, wonach leere else Blöcke praktisch immer eine schädliche Verschwendung von elektronischer Tinte sind. Fügen Sie diese nicht hinzu, es sei denn, Sie haben einen sehr guten Grund dafür. In diesem Fall sollte der leere Block überhaupt nicht leer sein. Er sollte einen Kommentar enthalten, der erklärt, warum er dort ist.

Das Problem der Vermeidung von Negativen verdient jedoch etwas mehr Aufmerksamkeit: Wenn Sie einen booleschen Wert verwenden müssen, benötigen Sie normalerweise einige Codeblöcke, um zu arbeiten, wenn sie festgelegt sind, und einige andere Blöcke, um zu arbeiten, wenn sie nicht festgelegt sind. Wenn Sie also eine Regel ohne Negative erzwingen, erzwingen Sie entweder if() {} else {...} Anweisungen (mit einem leeren if Block!) Oder Sie erstellen einen zweiten Booleschen Wert für jeden Booleschen Wert, der seine enthält negierter Wert. Beide Optionen sind schlecht, da sie Ihre Leser verwirren.

Eine hilfreiche Richtlinie lautet: Verwenden Sie niemals ein negiertes Formular innerhalb des Namens eines Booleschen Wertes und drücken Sie die Negation als einzelne ! Aus. Eine Aussage wie if(!doorLocked) ist vollkommen klar, eine Aussage wie if(!doorUnlocked) knotet das Gehirn. Die spätere Art des Ausdrucks ist das, was Sie unbedingt vermeiden müssen, nicht das Vorhandensein eines einzelnen ! In einer if() Bedingung.

... auf eine if-Anweisung sollte eine else-Anweisung folgen, unabhängig davon, ob etwas darin enthalten ist oder nicht.

Ich bin nicht einverstanden, dass if (a) { } else { b(); } als if (!a) { b(); } und if (a) { b(); } else { } als if (a) { b(); } neu geschrieben werden sollte.

Es sei jedoch darauf hingewiesen, dass ich selten einen leeren Zweig habe. Dies liegt daran, dass ich normalerweise protokolliere, dass ich in den ansonsten leeren Zweig gegangen bin. Auf diese Weise kann ich reine Protokollnachrichten entwickeln. Ich benutze selten einen Debugger. In Produktionsumgebungen erhalten Sie keinen Debugger. Es ist schön, Produktionsprobleme mit denselben Tools beheben zu können, die Sie für die Entwicklung verwenden.

Zweitens ist es besser, auf wahre Werte zu testen, als auf falsche. Das bedeutet, dass es besser ist, eine 'doorClosed'-Variable anstelle einer'! DoorOpened'-Variablen zu testen

Ich habe gemischte Gefühle. Ein Nachteil von doorClosed und doorOpened ist, dass sich möglicherweise die Anzahl der Wörter/Begriffe verdoppelt, die Sie beachten müssen. Ein weiterer Nachteil ist, dass sich im Laufe der Zeit die Bedeutung von doorClosed und doorOpened ändern kann (andere Entwickler kommen nach Ihnen) und Sie möglicherweise zwei Eigenschaften haben, die keine präzisen Negationen mehr voneinander sind. Anstatt Negationen zu vermeiden, schätze ich es, die Sprache des Codes (Klassennamen, Variablennamen usw.) an das Vokabular der Geschäftsbenutzer und an die Anforderungen anzupassen, die mir gestellt werden. Ich möchte keinen neuen Begriff erfinden, um einen ! Zu vermeiden, wenn dieser Begriff nur für einen Entwickler eine Bedeutung hat, die Geschäftsbenutzer nicht verstehen. Ich möchte, dass Entwickler dieselbe Sprache sprechen wie die Benutzer und die Personen, die Anforderungen schreiben. Wenn neue Begriffe das Modell vereinfachen, ist das wichtig, aber das sollte behandelt werden, bevor die Anforderungen abgeschlossen sind, nicht danach. Die Entwicklung sollte dieses Problem lösen, bevor mit dem Codieren begonnen wird.

Ich neige dazu, an meinem Instinkt zu zweifeln.

Es ist gut, sich weiterhin selbst in Frage zu stellen.

Ist es eine gute/schlechte/"egal" -Praxis?

Bis zu einem gewissen Grad spielt vieles davon keine Rolle. Lassen Sie Ihren Code überprüfen und passen Sie ihn an Ihr Team an. Das ist normalerweise richtig. Wenn jeder in Ihrem Team auf eine bestimmte Weise codieren möchte, ist es wahrscheinlich am besten, dies auf diese Weise zu tun (das Ändern einer Person - Sie selbst - erfordert weniger Story-Punkte als das Ändern einer Gruppe von Personen).

Ist es übliche Praxis?

Ich kann mich nicht erinnern, jemals einen leeren Zweig gesehen zu haben. Ich sehe jedoch Leute, die Eigenschaften hinzufügen, um Negationen zu vermeiden.

0

Ich würde sagen, es ist definitiv eine schlechte Praxis. Wenn Sie else-Anweisungen hinzufügen, werden Ihrem Code eine ganze Reihe sinnloser Zeilen hinzugefügt, die nichts bewirken und das Lesen noch schwieriger machen.

0
ayrton clark

Es gibt ein anderes Muster, das noch nicht erwähnt wurde, um den zweiten Fall zu behandeln, der einen leeren if-Block hat. Eine Möglichkeit, damit umzugehen, wäre die Rückkehr in den if-Block. So was:

void foo()
{
    if (condition) return;

    doStuff();
    ...
}

Dies ist ein gängiges Muster zum Überprüfen von Fehlerbedingungen. Der positive Fall wird immer noch verwendet, und das Innere ist nicht mehr leer, sodass zukünftige Programmierer sich fragen können, ob ein No-Op beabsichtigt war oder nicht. Dies kann auch die Lesbarkeit verbessern, da Sie möglicherweise eine neue Funktion erstellen müssen (wodurch große Funktionen in kleinere Einzelfunktionen aufgeteilt werden).

0
Shaz

Ich werde nur den zweiten Teil der Frage ansprechen, und dies kommt aus meiner Sicht der Arbeit in industriellen Systemen und der Manipulation von Geräten in der realen Welt.

Dies ist jedoch in gewisser Weise eher ein erweiterter Kommentar als eine Antwort.

Wenn es heißt

Zweitens ist es besser, auf wahre Werte zu testen, als auf falsche. Das bedeutet, dass es besser ist, eine 'doorClosed'-Variable anstelle einer'! DoorOpened'-Variablen zu testen

Sein Argument ist, dass es klarer macht, was der Code tut.

Aus meiner Sicht wird hier die Annahme gemacht, dass der Türzustand ein binärer Zustand ist, obwohl es sich tatsächlich zumindest um einen ternären Zustand handelt:

  1. Die Tür ist offen.
  2. Die Tür ist weder vollständig geöffnet noch vollständig geschlossen.
  3. Die Tür ist geschlossen.

Je nachdem, wo sich ein einzelner binärer digitaler Sensor befindet, können Sie nur eines von zwei Konzepten vermuten:

  1. Befindet sich der Sensor auf der offen Seite der Tür: Die Tür ist entweder offen oder nicht geöffnet
  2. Befindet sich der Sensor auf der geschlossenen Seite der Tür: Die Tür ist entweder geschlossen oder nicht geschlossen.

Und Sie können diese Konzepte nicht durch die Verwendung einer binären Negation austauschen. Daher sind doorClosed und !doorOpened Wahrscheinlich nicht synonym, und jeder Versuch, so zu tun, als wären sie synonym, ist ein falsches Denken, das eine größere Kenntnis des Systemzustands voraussetzt, als tatsächlich vorhanden ist.

Wenn ich auf Ihre Frage zurückkomme, würde ich eine Sprache unterstützen, die mit dem Ursprung der Informationen übereinstimmt, die die Variable darstellt. Wenn die Informationen also von der geschlossenen Seite der Tür stammen, gehen Sie zu doorClosed usw. Dies kann bedeuten, dass je nach Bedarf entweder doorClosed oder !doorClosed In verschiedenen Anweisungen verwendet wird. was zu einer möglichen Verwechslung mit der Verwendung der Negation führt. Was es jedoch nicht tut, ist implizit Annahmen über den Zustand des Systems zu verbreiten.


Zu Diskussionszwecken für meine Arbeit hängt die Menge an Informationen, die mir über den Status des Systems zur Verfügung stehen, von der Funktionalität ab, die das Gesamtsystem selbst benötigt.

Manchmal muss ich nur wissen, ob die Tür geschlossen ist oder nicht. In diesem Fall reicht nur ein einziger Binärsensor aus. Aber zu anderen Zeiten muss ich wissen, dass die Tür offen, geschlossen oder im Übergang ist. In solchen Fällen würde es entweder zwei binäre Sensoren geben (bei jedem Extrem der Türbewegung - mit Fehlerprüfung gegen gleichzeitiges Öffnen und Schließen der Tür) oder es würde einen analogen Sensor geben, der misst, wie "offen" die Tür war.

Ein Beispiel für die erste wäre die Tür eines Mikrowellenofens. Sie aktivieren den Betrieb des Ofens basierend darauf, ob die Tür geschlossen oder nicht geschlossen ist. Es ist dir egal, wie offen die Tür ist.

Ein Beispiel für den zweiten wäre ein einfacher motorbetriebener Aktuator. Sie verhindern das Vorwärtsfahren des Motors, wenn der Antrieb vollständig ausgeschaltet ist. Und Sie verhindern das Rückwärtsfahren des Motors, wenn der Antrieb vollständig eingeschaltet ist.

Grundsätzlich kommt es bei Anzahl und Art der Sensoren darauf an, eine Kostenanalyse der Sensoren anhand einer Anforderungsanalyse durchzuführen, um festzustellen, was zur Erreichung der erforderlichen Funktionalität erforderlich ist.

0
Peter M

Es gibt einen Punkt bei der Betrachtung des Arguments "Immer eine else-Klausel haben", den ich in keiner anderen Antwort gesehen habe: Es kann in einem funktionalen Programmierstil sinnvoll sein. Art von.

In einem funktionalen Programmierstil handeln Sie eher mit Ausdrücken als mit Anweisungen. Jeder Codeblock hat also einen Rückgabewert - einschließlich eines if-then-else Ausdruck. Dies würde jedoch einen leeren else Block ausschließen. Lassen Sie mich ein Beispiel geben:

var even = if (n % 2 == 0) {
  return "even";
} else {
  return "odd";
}

In Sprachen mit C-Stil oder C-Stil-inspirierter Syntax (wie Java, C # und JavaScript, um nur einige zu nennen) sieht dies seltsam aus. Es sieht jedoch viel vertrauter aus, wenn es als solches geschrieben wird:

var even = (n % 2 == 0) ? "even" : "odd";

Wenn Sie den Zweig else hier leer lassen, wird ein Wert undefiniert - in den meisten Fällen nicht das, was wir als gültigen Fall für die Programmierfunktionalität wünschen. Gleiches gilt, wenn man es komplett weglässt. Wenn Sie jedoch iterativ programmieren, habe ich kaum einen Grund angegeben, immer einen else -Block zu haben.

0
blalasaadri