Qual è il ragionamento alla base del fatto di inserire le costanti nelle istruzioni if?

Question

Stavo guardando alcuni esempi di codice C++ per un'interfaccia hardware sto lavorando con e ho notato un sacco di dichiarazioni secondo le seguenti linee:

if (NULL == pMsg) return rv; 

Sono sicuro che ho sentito dire che mettere il costante prima è una buona idea, ma perché è così? È così che se hai una dichiarazione importante puoi vedere rapidamente a cosa stai confrontando o c'è dell'altro?

Answer 1

In modo da non mischiare il confronto (==) con l'assegnazione (=).

Come sapete, non è possibile assegnare a una costante. Se ci provi, il complatore ti darà un errore.

Fondamentalmente, è una delle tecniche di programmazione difensive. Per proteggersi da te stesso.

Answer 2

Quando la costante è la prima, il compilatore ti avviserà se scrivi accidentalmente = anziché == poiché è illegale assegnare un valore a una costante.

Answer 3

che impedisca di scrittura:

if (pMsg = NULL) return rv; 

per errore. Tuttavia, un buon compilatore ti avviserà di questo, quindi la maggior parte delle persone non usa il modo "costante prima", poiché trova difficile leggere.

Answer 4

Arresta il bug single = assignment.

Ad esempio,

if (NULL = pMsg) return rv; 

non si compila, dove come

if (pMsg = NULL) return rv; 

compilerà e darà mal di testa

Answer 5

Hanno detto, "per evitare la miscelazione di assegnazione e di confronto".

In realtà penso che sia una sciocchezza: se siete modo disciplinato che non si dimentica di mettere costante sul lato sinistro, si sicuramente non mischiare '=' con '==' , vorresti? ;)

Answer 6

I compilatori che emettono avvisi sono buoni, ma alcuni di noi nel mondo reale non possono permettersi di trattare gli avvertimenti come errori. Invertire l'ordine di variabile e costante significa che questo semplice slittamento appare sempre come un errore e impedisce la compilazione. Ci si abitua molto velocemente a questo schema e l'insetto contro cui è protetto è sottile, che è spesso difficile da trovare una volta introdotto.

Answer 7

Per chiarire cosa ho scritto in alcuni commenti, ecco un motivo non per farlo in codice C++.

Qualcuno scrive, ad esempio, una classe string e decide di aggiungere un operatore di cast per const char*:

class BadString 
{ 
public: 
    BadString(const char* s) : mStr(s) { } 

    operator const char*() const { return mStr.c_str(); } 

    bool operator==(const BadString& s) { return mStr == s.mStr; } 

    // Other stuff... 

private: 
    std::string mStr; 
}; 

Ora qualcuno si applica ciecamente il modello constant == variable programmazione "difensivo":

BadString s("foo"); 

if ("foo" == s) // Oops. This compares pointers and is never true. 
{ 
    // ... 
} 

Questo è , IMO, un problema più insidioso dell'assegnazione accidentale perché non si può dire dal sito di chiamata che qualcosa è ovviamente sbagliato.

Naturalmente, le vere lezioni sono:

1. Non scrivere le proprie classi di stringa.
2. Evita gli operatori di cast impliciti, specialmente quando si esegue (1).

Ma a volte hai a che fare con API di terze parti che non puoi controllare. Ad esempio, il comune della classe di stringa _bstr_t nella programmazione COM di Windows soffre di questo difetto.

Answer 8

ho dimenticato l'articolo, ma la citazione è andato qualcosa come: "Evidentemente è più facile ricordarsi di mettere la prima costante, che si sta ricordando di usare ==";))