Gibt es einen Grund für die Verwendung von if(1 || !Foo())?

Ich habe etwas Legacy-Code gelesen:

if ( 1 || !Foo() )

Gibt es einen ersichtlichen Grund, warum man nicht schreibt:

if ( !Foo() )

Die beiden sind nicht das Gleiche. Der erste wird niemals evaluieren Foo() weil die 1 Kurzschlüsse die ||.

Warum es so ist – vermutlich wollte jemand den Zutritt erzwingen then Verzweigung zu Debugging-Zwecken und beließ sie dort. Es könnte auch sein, dass dies vor der Quellcodeverwaltung geschrieben wurde, also wollten sie nicht, dass der Code verloren geht, sondern nur umgangen wird zur Zeit.

if (1 || !Foo() ) wird immer zufrieden sein. !Foo() wird nicht einmal wegen erreicht werden Kurzschlussauswertung.

Dies geschieht, wenn Sie sicherstellen möchten, dass der Code unter dem if wird ausgeführt, aber Sie möchten die nicht entfernen real Bedingung darin, wahrscheinlich für Debug-Zwecke.

Zusätzliche Informationen, die Ihnen helfen könnten:

• if(a && b) – wenn a ist false, b wird nicht geprüft.
• if(a && b) – wenn a ist true, b wird überprüft, denn wenn es ist falsewird der Ausdruck sein false.
• if(a || b) – wenn a ist true, b wird nicht überprüft, weil dies der Fall ist true ohnehin.
• if(a || b) – wenn a ist false, b wird überprüft, denn wenn b ist true dann wird es sein true.

Es wird beispielsweise dringend empfohlen, ein Makro für diesen Zweck zu haben DEBUG_ON 1das macht es einfacher zu verstehen, was der Programmierer meint, und nicht zu haben magische Zahlen im Code (Danke @grigeshchauhan).

1 || condition

gilt immer, egal ob die condition wahr ist oder nicht. In diesem Fall ist die condition wird auch nie ausgewertet. Der folgende Code:

int c = 5;
if (1 || c++){}
printf("%d", c);

Ausgänge 5 seit c wird nie erhöht, jedoch wenn Sie sich geändert haben 1 zu 0das c++ würde tatsächlich aufgerufen werden, wodurch die Ausgabe erfolgt 6.

Eine übliche praktische Verwendung davon ist in der Situation, wenn Sie einen Codeabschnitt testen möchten, der aufgerufen wird, wenn die Bedingung, die als wahr ausgewertet wird, nur selten erfüllt ist:

if (1 || condition ) {
    // code I want to test
}

Diesen Weg condition wird nie ausgewertet und daher // code I want to test immer aufgerufen. Es ist jedoch definitiv nicht dasselbe wie:

if (condition) { ...

das ist eine Aussage wo condition wird tatsächlich ausgewertet (und in Ihrem Fall Foo wird angerufen werden)

Die Frage wurde richtig beantwortet – der Unterschied besteht darin, dass die rechte Seite der or-Operation kurzgeschlossen ist, was darauf hindeutet, dass dies ein Debug-Code ist, um den Eintritt in den if-Block zu erzwingen.

Aber im Interesse von Best Practices, zumindest meinem groben Stich in eine Best Practice, würde ich Alternativen in der Reihenfolge zunehmender Präferenz vorschlagen (das Beste kommt zuletzt):

Hinweis: Nachdem ich Beispiele codiert habe, ist mir aufgefallen, dass dies eine C++-Frage war, Beispiele sind C#. Hoffentlich kannst du übersetzen. Wenn mich jemand braucht, poste einfach einen Kommentar.

Inline-Kommentar:

if (1 /*condition*/) //temporary debug

Out-of-line-Kommentar:

//if(condition)
if(true) //temporary debug

Namensgebende Funktion

//in some general-use container
bool ForceConditionForDebug(bool forcedResult, string IgnoredResult)
{
      #if DEBUG
          Debug.WriteLine(
              string.Format(
                  "Conditional {0} forced to {1} for debug purposes",
                  IgnoredResult,
                  forcedResult));
          return forcedResult;
      #else
          #if ALLOW_DEBUG_CODE_IN_RELEASE
              return forcedResult;
          #else
              throw new ApplicationException("Debug code detected in release mode");
          #endif
      #endif
}

//Where used
if(ForceConditionForDebug(true, "condition"))...

//Our case
if(ForceConditionForDebug(true, "!Foo()"))...

Und wenn Sie eine wirklich robuste Lösung wollten, könnten Sie der Quellcodeverwaltung eine Repository-Regel hinzufügen, um jeden eingecheckten Code abzulehnen, der ForceConditionForDebug aufruft. Dieser Code hätte niemals so geschrieben werden dürfen, da er offensichtlich keine Absicht kommuniziert. Es hätte niemals eingecheckt werden dürfen (oder eingecheckt werden dürfen) (Quellcodeverwaltung? Peer-Review?) Und es sollte auf keinen Fall in der aktuellen Form in der Produktion ausgeführt werden dürfen.