C'è qualche motivo per usare se (1 ||! Foo())?

Question

Ho letto alcuni codice legacy:

if (1 || !Foo()) 

C'è qualche motivo per cui visto non scrivere:

if (!Foo()) 

Answer 1

i due non sono lo stesso. Il primo non valuterà mai Foo() perché il 1 cortocircuiti lo ||.

Perché è stato fatto - probabilmente qualcuno ha voluto forzare l'immissione nel ramo then per il debug e lo ha lasciato lì. Potrebbe anche essere che questo è stato scritto prima del controllo del codice sorgente, quindi non volevano che il codice andasse perso, piuttosto semplicemente bypassato per ora.

Answer 2

1 || condition 

è sempre vero, indipendentemente dal fatto che condition sia vero o meno. In questo caso, lo condition non viene mai nemmeno valutato. Il codice seguente:

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

uscite 5 dal c viene mai incrementato, se è stato modificato 1 a 0, il c++ sarebbe effettivamente chiamati, rendendo l'uscita 6.

---

un normale utilizzo pratico di questo è nella situazione in cui si vuole testare qualche pezzo di codice che viene richiamato quando la condizione che restituisce true solo raramente è soddisfatta:

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

Questo modo condition non verrà mai valutato e pertanto viene invocato sempre // code I want to test. Tuttavia non è assolutamente la stessa:

if (condition) { ... 

che è una dichiarazione in cui sarà effettivamente essere valutati condition (e nel tuo caso sarà chiamato Foo)

Answer 3

if (1 || !Foo()) sarà sempre soddisfatti. !Foo() non sarà nemmeno raggiunto a causa di short-circuits evaluation.

Questo accade quando si vuole fare in modo che venga eseguito il codice sotto il if, ma non si vuole rimuovere il vero condizioni in esso, probabilmente a scopo di debug.

Ulteriori informazioni che potrebbero aiutarvi:

• if(a && b) - se a è false, non verrà controllato b.
• if(a && b) - se a è true, b sarà controllato, perché se è false, l'espressione sarà false.
• if(a || b) - se a è true, non verrà controllato, perché questo è true comunque.
• if(a || b) - se a è false, b sarà controllato, perché se è btrue allora sarà true.

---

Si consiglia vivamente di avere una macro per questo scopo, dicono DEBUG_ON 1, che renderà più facile per capire che cosa i mezzi programmatore, e non avere numeri magici nel codice (Grazie @grigeshchauhan).

Answer 4

La domanda è stata risolta correttamente - la differenza è il lato destro dell'operazione o è cortocircuitata, suggerendo che questo è il codice di debug per forzare l'ingresso nel blocco if.

ma nell'interesse delle migliori pratiche, almeno il mio pugnalata di massima a una best practice, io suggerirei di alternative, in ordine crescente di preferenza (migliore è l'ultima):

nota: notato dopo ho codificato esempi questa era una domanda in C++, gli esempi sono C#. Spero che tu possa tradurre. Se qualcuno ha bisogno di me, basta pubblicare un commento.

In-riga di commento:

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

Out-of-riga di commento:

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

Nome-indicativo Funzione

//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()"))... 

e se si voleva una soluzione davvero robusta, è possibile aggiungere una regola di repository al controllo del codice sorgente per rifiutare qualsiasi codice archiviato denominato ForceConditionForDebug. Questo codice non dovrebbe mai essere stato scritto in quel modo perché ovviamente non comunica l'intento. Non avrebbe mai dovuto essere archiviato (o permesso di essere registrato) (controllo del codice sorgente? Peer review?) E non dovrebbe mai essere permesso di eseguire in produzione nella sua forma attuale.