Qual è lo scopo dell'uso delle parentesi graffe (ad es. {}) Per un ciclo if o a riga singola?

Sto leggendo alcuni appunti del mio docente di C ++ e ha scritto quanto segue:

1. Usa rientro // OK
2. Non fare mai affidamento sulla precedenza dell'operatore - Usa sempre le parentesi // OK
3. Usa sempre un blocco {} - anche per una singola riga // non OK , perché ???
4. Const oggetto sul lato sinistro del confronto // OK
5. Usa unsigned per le variabili che sono> = 0 // bel trucco
6. Impostare il puntatore su NULL dopo l'eliminazione - Doppia protezione dall'eliminazione // non male

La terza tecnica non mi è chiara: cosa guadagnerei posizionando una riga in a { ... }?

Ad esempio, prendi questo strano codice:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

e sostituiscilo con:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

Quali sono i vantaggi dell'utilizzo della prima versione?

Proviamo a modificare anche iquando incrementiamo j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

Oh no! Proveniente da Python, questo sembra ok, ma in realtà non lo è, in quanto equivale a:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Certo, questo è un errore sciocco, ma che anche un programmatore esperto potrebbe fare.

Un altro ottimo motivo è indicato nella risposta di ta.speot.is .

Un terzo che mi viene in mente è nidificato if:

if (cond1)
   if (cond2) 
      doSomething();

Ora, supponiamo che ora lo desideri doSomethingElse()quando cond1non è soddisfatto (nuova funzionalità). Così:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

che è ovviamente sbagliato, dal momento che i elsesoci con l'interno if.

Modifica: dal momento che sta ottenendo una certa attenzione, chiarirò il mio punto di vista. La domanda a cui stavo rispondendo è:

Quali sono i vantaggi dell'utilizzo della prima versione?

Che ho descritto. Ci sono alcuni vantaggi Ma, IMO, le regole "sempre" non si applicano sempre. Quindi non sostengo del tutto

Usa sempre un blocco {} - anche per una singola riga // non OK, perché ???

Non sto dicendo di usare sempre un {}blocco. Se è una condizione e un comportamento abbastanza semplici, non farlo. Se sospetti che qualcuno possa entrare in seguito e modificare il codice per aggiungere funzionalità, fallo.

È molto facile cambiare accidentalmente il flusso di controllo con commenti se non lo si utilizza {e }. Per esempio:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

Se commenti do_something_else()con un commento a riga singola, finirai con questo:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

Si compila, ma must_always_do_this()non viene sempre chiamato.

Abbiamo riscontrato questo problema nella nostra base di codice, in cui qualcuno aveva disattivato alcune funzionalità molto rapidamente prima del rilascio. Fortunatamente l'abbiamo preso nella revisione del codice.

Ho i miei dubbi sulla competenza del docente. Considerando i suoi punti:

1. ok
2. Qualcuno scriverà davvero (o vorrebbe leggere) (b*b) - ((4*a)*c)? Alcune precedenti sono ovvie (o dovrebbero esserlo) e le parentesi extra aggiungono solo confusione. (D'altra parte, dovresti usare le parentesi in casi meno ovvi, anche se sai che non sono necessari.)
3. Una specie di. Esistono due convenzioni diffuse per la formattazione di condizionali e loop:

   if (cond) {
       codice;
   }
   

   e:

   if (cond)
   {
       codice;
   }
   

   Nel primo, sono d'accordo con lui. L'apertura {non è così visibile, quindi è meglio supporre che sia sempre lì. Nel secondo, tuttavia, io (e la maggior parte delle persone con cui ho lavorato) non ho alcun problema a omettere le parentesi graffe per una singola affermazione. (A condizione, ovviamente, che il rientro sia sistematico e che usi questo stile in modo coerente. (E molti programmatori molto bravi, scrivendo codice molto leggibile, omettono le parentesi graffe anche quando si formatta il primo modo.)
4. NO . Cose del genere if ( NULL == ptr )sono abbastanza brutte da ostacolare la leggibilità. Scrivi i confronti in modo intuitivo. (Il che in molti casi si traduce nella costante a destra.) Il suo 4 è un cattivo consiglio; tutto ciò che rende il codice innaturale lo rende meno leggibile.
5. NO . Tutto tranne che intè riservato per casi speciali. Per programmatori esperti in C e C ++, l'uso di unsignedsegnali bit operatori. Il C ++ non ha un vero tipo cardinale (o qualsiasi altro tipo di subrange efficace); unsignednon funziona per valori numerici, a causa delle regole di promozione. Valori numerici sui quali nessuna operazione aritmetica avrebbe senso, come i numeri di serie, presumibilmente potrebbero esserlo unsigned. Discuterei contro, tuttavia, perché invia il messaggio sbagliato: neanche le operazioni bit a bit hanno senso. La regola di base è che i tipi integrali sono int_unless_ c'è una ragione significativa per usare un altro tipo.
6. NO . Farlo sistematicamente è fuorviante e in realtà non protegge da nulla. Nel rigoroso codice OO, delete this;è spesso il caso più frequente (e non è possibile impostarlo thissu NULL), altrimenti la maggior parte deletesono in distruttori, quindi non è possibile accedere al puntatore in seguito comunque. E impostarlo su NULLnon fa nulla riguardo ad altri puntatori che fluttuano intorno. Impostando il puntatore in modo sistematico su si NULLottiene un falso senso di sicurezza e non si acquista davvero nulla.

Guarda il codice in uno dei riferimenti tipici. Stroustrup viola ogni regola che hai dato ad eccezione della prima, ad esempio.

Ti suggerirei di trovare un altro docente. Uno che sa davvero di cosa sta parlando.

Tutte le altre risposte difendono la regola del docente 3.

Lasciami dire che sono d'accordo con te: la regola è ridondante e non la consiglierei. È vero che teoricamente previene gli errori se aggiungi sempre parentesi graffe. D'altra parte, non ho mai riscontrato questo problema nella vita reale : contrariamente a quanto implicano altre risposte, non ho dimenticato una volta di aggiungere le parentesi graffe una volta diventate necessarie. Se si utilizza il rientro corretto, diventa immediatamente ovvio che è necessario aggiungere parentesi graffe una volta rientrata più di un'istruzione.

La risposta di "Component 10" evidenzia in realtà l'unico caso immaginabile in cui ciò potrebbe davvero portare a un errore. D'altra parte, la sostituzione del codice con l'espressione regolare richiede comunque un'enorme cura.

Ora diamo un'occhiata all'altro lato della medaglia: c'è uno svantaggio di usare sempre parentesi graffe? Le altre risposte ignorano semplicemente questo punto. Ma v'è uno svantaggio: ci vuole un sacco di spazio sullo schermo in verticale, e questo a sua volta può rendere il codice illeggibile, perché significa che si deve scorrere più del necessario.

Considera una funzione con molte clausole guard all'inizio (e sì, il seguente è un codice C ++ errato ma in altre lingue questa sarebbe una situazione abbastanza comune):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

Questo è un codice orribile, e sostengo fortemente che quanto segue sia molto più leggibile:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

Allo stesso modo, i cicli nidificati brevi traggono beneficio dall'omissione delle parentesi graffe:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

Confrontare con:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

Il primo codice è conciso; il secondo codice è gonfio.

E sì, questo può essere mitigato in una certa misura mettendo la parentesi graffa di apertura sulla riga precedente. Ma sarebbe comunque meno leggibile del codice senza parentesi graffe.

In breve: non scrivere codice non necessario che occupa spazio sullo schermo.

La base di codice su cui sto lavorando è disseminata di codice da parte di persone con avversione patologica alle parentesi graffe e, per le persone che vengono dopo, può davvero fare la differenza per la manutenibilità.

L'esempio problematico più frequente che ho riscontrato è questo:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

Quindi quando arrivo e desidero aggiungere un'istruzione then, posso facilmente finire con questo se non sto attento:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

Dato che ci vuole ~ 1 secondo per aggiungere le parentesi graffe e si può risparmiare al minimo pochi minuti confusi debug, perché mai non andare con l'opzione ridotto l'ambiguità? Mi sembra una falsa economia.

Il mio 2c:

Usa rientro

Ovviamente

Non fare mai affidamento sulla precedenza dell'operatore - Utilizzare sempre le parentesi

Non userei le parole "mai e" sempre ", ma in generale vedo questa regola utile. In alcune lingue (Lisp, Smalltalk) questo non è un problema.

Usa sempre un blocco {}, anche per una singola riga

Non lo faccio mai e non ho mai avuto un singolo problema, ma posso vedere come può essere buono per gli studenti, esp. se avessero studiato Python prima.

Costante oggetto sul lato sinistro del confronto

Condizioni di Yoda? No per favore. Fa male la leggibilità. Usa il massimo livello di avviso quando compili il tuo codice.

Usa unsigned per variabili che sono> = 0

OK. Abbastanza divertente, ho sentito che Stroustrup non è d'accordo.

Impostare il puntatore su NULL dopo l'eliminazione: doppia protezione dall'eliminazione

Pessimo consiglio! Non avere mai un puntatore che punta a un oggetto cancellato o inesistente.

è più intuitivo e facilmente comprensibile. Rende chiaro l'intento.

E assicura che il codice non si rompa quando un nuovo utente potrebbe inconsapevolmente perdere il {, }mentre aggiunge una nuova istruzione di codice.

Per aggiungere ai suggerimenti molto sensati sopra, un esempio che ho riscontrato durante il refactoring di un codice in cui questo diventa critico era il seguente: Stavo modificando una base di codice molto grande per passare da un'API all'altra. La prima API ha ricevuto una chiamata per impostare l'ID azienda come segue:

setCompIds( const std::string& compId, const std::string& compSubId );

mentre la sostituzione ha richiesto due chiamate:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

Ho deciso di cambiarlo usando espressioni regolari che hanno avuto molto successo. Abbiamo anche passato il codice attraverso astyle , il che lo ha reso molto più leggibile. Quindi, a metà del processo di revisione, ho scoperto che in alcune circostanze condizionate stava cambiando questo:

if ( condition )
   setCompIds( compId, compSubId );

A questa:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

che chiaramente non è ciò che era richiesto. Ho dovuto tornare all'inizio per farlo di nuovo trattando la sostituzione come completamente all'interno di un blocco e quindi alterando manualmente tutto ciò che alla fine sembrava sciocco (almeno non sarebbe errato.)

Ho notato che astyle ora ha l'opzione --add-bracketsche ti consente di aggiungere parentesi dove non ce ne sono e lo consiglio vivamente se ti trovi mai nella stessa posizione in cui ero.

Sto usando {}ovunque tranne alcuni casi in cui è ovvio. La linea singola è uno dei casi:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

Potrebbe farti male quando aggiungi qualche metodo prima del ritorno. Il rientro indica che il ritorno è in esecuzione quando viene soddisfatta la condizione, ma tornerà sempre.

Altro esempio in C # con l'utilizzo di statment

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

che equivale a

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

L'esempio più pertinente che mi viene in mente:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

Con quale ifsarà elseaccoppiato? Il rientro implica che l'esterno ifottenga il else, ma non è così che il compilatore lo vedrà; l' interno if otterrà elsee l'esterno ifno. Dovresti sapere che (o vederlo comportarsi in quel modo in modalità di debug) per capire perché questo codice potrebbe non soddisfare le tue aspettative. Diventa più confuso se conosci Python; in quel caso sai che il rientro definisce i blocchi di codice, quindi ti aspetteresti che valuti in base al rientro. C #, tuttavia, non dà una svolta al volo per gli spazi bianchi.

Ora, detto questo, non sono particolarmente d'accordo con questa regola "usa sempre le parentesi" sulla sua faccia. Rende il codice molto verticalmente rumoroso, riducendo la capacità di leggerlo rapidamente. Se la dichiarazione è:

if(someCondition)
   DoSomething();

... allora dovrebbe essere scritto proprio così. L'istruzione "usa sempre parentesi" suona come "circonda sempre le operazioni matematiche tra parentesi". Ciò trasformerebbe la semplice affermazione a * b + c / din ((a * b) + (c / d)), introducendo la possibilità di perdere un paren vicino (la rovina di molti programmatori), e per cosa? L'ordine delle operazioni è ben noto e applicato, quindi le parentesi sono ridondanti. Utilizzeresti solo le parentesi per imporre un ordine delle operazioni diverso da quello normalmente applicato: a * (b+c) / dad esempio. Le parentesi graffe sono simili; usali per definire cosa vuoi fare nei casi in cui differisce dal valore predefinito e non è "ovvio" (soggettivo, ma di solito piuttosto buon senso).

Guardando attraverso le risposte nessuno ha dichiarato esplicitamente il tipo di pratica di cui ho l'abitudine, raccontando la storia del tuo codice:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

diventa:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

Mettere il j++sulla stessa linea come se dovrebbe segnalare a chiunque altro, "Voglio solo che questo blocco di incremento mai j" . Di coursethis vale la pena solo se la linea è semplice possibile, perché mettere un punto di interruzione qui, come peri menzioni, non sta per essere molto utile.

In effetti ho appena incontrato parte dell'API Storm di Twitter che ha questo "tipo" di codice in Java, ecco lo snippet relvant dal codice di esecuzione, a pagina 43 di questa presentazione :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

Il blocco del ciclo for ha due elementi, quindi non vorrei incorporare quel codice. Cioè mai :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

È orribile e non so nemmeno se funziona (come previsto); non farlo . Nuove linee e parentesi graffe aiutano a distinguere parti di codice separate ma correlate, come fanno in prosa una virgola o un punto e virgola. Il blocco sopra è una frase davvero lunga con alcune clausole e alcune altre dichiarazioni che non si rompono o si fermano mai per distinguere parti separate.

Se vuoi davvero telegrafare a qualcun altro è un lavoro su una sola riga, usa un operatore ternario o un ?:modulo:

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

Ma questo sta rasentando il code-golf, e penso che non sia una buona pratica (non mi è chiaro se dovrei mettere j ++ da un lato :o meno). NB: non ho mai eseguito un operatore ternario in C ++ prima, non so se funziona, ma esiste .

In breve:

Immagina come il tuo lettore (cioè la persona che mantiene il codice) interpreta la tua storia (codice). Renderlo il più chiaro possibile per loro. Se sai che lo studente / programmatore principiante lo sta mantenendo, forse lascialo nel maggior numero {}possibile, solo per non confonderlo.

Perché quando hai due dichiarazioni senza {}, è facile perdere un problema. Supponiamo che il codice assomigli a questo.

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

Sembra a posto. Il problema con esso è davvero facile da perdere, specialmente quando la funzione che contiene il codice è molto più grande. Il problema è che goto failviene eseguito incondizionatamente. Puoi facilmente immaginare quanto sia frustrante (farti chiedere perché l'ultimo hash_updatefallisce sempre, dopo tutto sembra hash_updatefunzionare bene ).

Tuttavia, ciò non significa che sto per aggiungere {}ovunque (a mio avviso, vedere {}ovunque è fastidioso). Anche se può causare problemi, non lo è mai stato per i miei progetti, poiché il mio stile di codifica personale proibisce i condizionali senza {}quando non sono sulla stessa linea (sì, sono d'accordo che il mio stile di codifica non è convenzionale, ma mi piace, e io utilizzare lo stile di codice del progetto quando si contribuisce ad altri progetti). Questo rende bene il seguente codice.

if (something) goto fail;

Ma non quello seguente.

if (something)
    goto fail;

Rende il tuo codice più leggibile definendo chiaramente l'ambito dei tuoi loop e blocchi condizionali. Ti salva anche da errori accidentali.

wrt 6: è più sicuro perché eliminare un puntatore null è un no-op. Quindi, se ti capita di percorrere accidentalmente quel percorso due volte, non causerai il danneggiamento della memoria liberando la memoria che è libera o è stata allocata a qualcos'altro.

Questo è in gran parte un problema con oggetti di ambito di file statici e singoli che non hanno una vita molto chiara e sono stati conosciuti per essere ricreati dopo che sono stati distrutti.

Nella maggior parte dei casi, puoi evitare la necessità usando auto_ptrs

Mi piace la risposta accettata di Luchian, infatti ho imparato a fondo che ha ragione, quindi uso sempre le parentesi graffe, anche per i blocchi a linea singola. Tuttavia, personalmente faccio un'eccezione quando scrivo un filtro, come nel tuo esempio. Questo:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

mi sembra ingombra. Separa il ciclo for e l'istruzione if in azioni separate, quando in realtà il tuo intento è una singola azione: contare tutti gli interi divisibili per 2. In un linguaggio più espressivo, questo potrebbe essere scritto come:

j = [1..100].filter(_%2 == 0).Count

Nelle lingue prive di chiusure, il filtro non può essere espresso in una singola istruzione, ma deve essere un ciclo for seguito da un'istruzione if. Tuttavia, è ancora un'azione nella mente del programmatore, e credo che dovrebbe riflettersi nel codice, in questo modo:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

Un'opzione per aiutare a prevenire gli errori che sono stati descritti in precedenza è quella di includere ciò che vuoi che accada quando non usi le parentesi graffe. Rende molto più difficile non notare gli errori quando si tenta di modificare il codice.

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

Se sei un compilatore, non fa alcuna differenza. Entrambi sono uguali.

Ma per i programmatori, il primo è più chiaro, facile da leggere e meno soggetto a errori.

Un altro esempio di aggiunta di parentesi graffe. Una volta stavo cercando un bug e ho trovato questo codice:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

Se leggi il metodo riga per riga noterai che esiste una condizione nel metodo che restituisce se non è vera. Ma in realtà sembra altri 100 semplici gestori di eventi che impostano alcune variabili in base ad alcune condizioni. E un giorno entra in Fast Coder e aggiunge un'ulteriore istruzione di impostazione delle variabili alla fine del metodo:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

Di conseguenza SetAnotherVariableUnconditionnaly viene eseguito quando SomeConditionIsMet (), ma il ragazzo veloce non se ne è accorto perché tutte le linee hanno dimensioni quasi simili e anche quando la condizione di ritorno è rientrata verticalmente non è così evidente.

Se il ritorno condizionale è formattato in questo modo:

if (!SomeConditionIsMet())
{
    return;
}

è molto evidente e il Fast Coder lo troverà a colpo d'occhio.

Considero il primo chiaro, poi il secondo. Dà la sensazione di chiudere le istruzioni, con poco codice va bene quando il codice diventa complesso {...}aiuta molto anche se lo è endifobegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Si consiglia di impostare il puntatore su NULL al termine.

Ecco un esempio del perché:

La classe A procede come segue:

1. Alloca un blocco di memoria
2. Quindi qualche tempo dopo, elimina questo blocco di memoria ma non imposta il puntatore su NULL

La classe B procede come segue

1. Alloca memoria (e in questo caso gli viene dato lo stesso blocco di memoria che è stato cancellato dalla classe A.)

A questo punto sia la Classe A che la Classe B hanno puntatori che puntano allo stesso blocco di memoria, per quanto riguarda la Classe A questo blocco di memoria non esiste perché è finito con esso.

Considera il seguente problema:

E se si fosse verificato un errore logico nella Classe A che lo ha portato a scrivere in memoria che ora appartiene alla Classe B?

In questo caso particolare, non si otterrà un errore di eccezione di accesso errato perché l'indirizzo di memoria è legale, nel frattempo la classe A ora sta effettivamente corrompendo i dati di classe B.

La classe B potrebbe eventualmente arrestarsi in modo anomalo se incontra valori imprevisti e quando si verifica un arresto anomalo, è probabile che trascorrerai molto tempo a cercare questo bug in classe B quando il problema è in classe A.

Se il puntatore della memoria eliminata fosse stato impostato su NULL, si sarebbe verificato un errore di eccezione non appena un errore logico nella classe A avesse tentato di scrivere sul puntatore NULL.

Se sei preoccupato per l'errore logico con la doppia eliminazione quando i puntatori sono NULL per la seconda volta, quindi aggiungi asserzione per questo.

Inoltre: se hai intenzione di votare in basso, spiega.

Avere sempre parentesi graffe è una regola molto semplice e robusta. Tuttavia, il codice potrebbe apparire non elegante quando ci sono molte parentesi graffe. Se le regole consentono di omettere parentesi graffe, dovrebbero esserci regole di stile più dettagliate e strumenti più sofisticati. Altrimenti può facilmente risultare con codice caotico e confuso (non elegante). Pertanto, la ricerca di una singola regola di stile separata dal resto delle guide di stile e degli strumenti utilizzati è probabilmente inutile. Porterò solo alcuni dettagli importanti su quella regola n. 3 che non sono stati nemmeno menzionati in altre risposte.

Il primo dettaglio interessante è che la maggior parte dei sostenitori di quella regola accetta di violarla in caso di else. In altre parole, non richiedono in revisione tale codice:

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

Invece, se lo vedono, possono anche suggerire di scriverlo in questo modo:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

Questa è tecnicamente violazione di quella regola poiché non ci sono parentesi graffe tra elsee if. Tale dualità della regola emerge quando provare ad applicarla automaticamente alla base di codice con uno strumento insensato. In effetti, perché discutere, basta lasciare uno strumento per applicare automaticamente lo stile.

Il secondo dettaglio (che viene spesso dimenticato dai sostenitori di quella regola) è che gli errori che possono verificarsi non sono mai solo a causa delle violazioni di quella regola n. 3. In realtà quelli quasi sempre comportano anche violazioni della regola n. 1 (di cui nessuno discute). Sempre dal punto di vista degli strumenti automatici, non è difficile creare uno strumento che si lamenta immediatamente quando viene violata la regola n. 1 e quindi la maggior parte degli errori può essere colta tempestivamente.

Il terzo dettaglio (che viene spesso dimenticato dagli avversari di quella regola) è la natura confusa dell'affermazione vuota che è rappresentata da un singolo punto e virgola. La maggior parte degli sviluppatori con una certa esperienza è stata confusa prima o poi da un solo punto e virgola fuori posto o da un'istruzione vuota che è scritta usando un solo punto e virgola. Due parentesi graffe invece del punto e virgola singolo sono visivamente molto più facili da individuare.

Devo ammettere che non sempre si usa {}per la linea singola, ma è una buona pratica.

• Diciamo che scrivi un codice senza parentesi che assomiglia a questo:

  per (int i = 0; i <100; ++ i) per (int j = 0; j <100; ++ j) DoSingleStuff ();

E dopo qualche tempo vuoi aggiungere in jloop alcune altre cose e lo fai semplicemente per allineamento e dimentica di aggiungere parentesi.

• La dislocazione della memoria è più veloce. Supponiamo che tu abbia un grande scopo e crei grandi array all'interno (senza di newche sono in pila). Tali array vengono rimossi dalla memoria subito dopo aver lasciato l'ambito. Ma è possibile che tu usi quell'array in un posto e rimarrà in pila per un po 'e sarà una specie di spazzatura. Poiché una pila ha dimensioni limitate e piuttosto ridotte, è possibile superare la dimensione della pila. Quindi in alcuni casi è meglio scrivere {}per evitarlo. NOTA questo non è per riga singola ma per tali situazioni:

  if (...) {// SomeStuff ... {// non abbiamo if, while, ecc. // SomeOtherStuff} // SomeMoreStuff}

• Il terzo modo di usarlo è simile al secondo. Semplicemente non per rendere più pulito lo stack ma per aprire alcune funzioni. Se si utilizza mutexin funzioni lunghe di solito è meglio bloccare e sbloccare appena prima di accedere ai dati e subito dopo aver finito di leggerlo / scriverlo. NOTA in questo modo si utilizza se ne hai alcuni classo structcon constructore destructorper bloccare la memoria.

• Inoltre:

  if (...) if (...) SomeStuff (); altro SomeOtherStuff (); // passa al secondo se, ma l'alligmento mostra che è il primo ...

Tutto sommato, non posso dire quale sia il modo migliore da usare sempre {}per una singola riga, ma non è niente di male farlo.

MODIFICA IMPORTANTE Se scrivi parentesi di codice di compilazione per una singola riga non fa nulla, ma se il tuo codice verrà interpretato, il codice verrà rallentato molto leggermente. Molto leggermente.

Esistono diversi modi per scrivere dichiarazioni di controllo; alcune combinazioni possono coesistere senza compromettere la leggibilità, ma altre combinazioni causeranno problemi. Lo stile

if (condition)
  statement;

coesisteranno comodamente con alcuni degli altri modi di scrivere dichiarazioni di controllo, ma non così bene con altri. Se le istruzioni controllate su più righe sono scritte come:

if (condition)
{
  statement;
  statement;
}

allora sarà visivamente ovvio quali ifistruzioni controllano una singola riga e quali controllano più righe. Se, tuttavia, multilineaif istruzioni sono scritte come:

if (condition) {
  statement;
  statement;
}

quindi la probabilità che qualcuno cerchi di estendere una singola affermazione if costrutto a senza aggiungere le parentesi graffe necessarie potrebbe essere molto più alta.

L'istruzione di riga singola sull'istruzione successiva ifpuò anche essere problematica se la base di codice fa un uso significativo del modulo

if (condition) statement;

La mia preferenza è che avere l'istruzione sulla propria linea generalmente migliora la leggibilità, tranne nei casi in cui ci sono molte ifistruzioni con blocchi di controllo simili, ad es.

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

nel qual caso in genere precederò e seguirò tali gruppi di ifistruzioni con una riga vuota per separarli visivamente da altri codici. Avere una serie di affermazioni che iniziano tutte con iflo stesso rientro fornirà quindi una chiara indicazione visiva che c'è qualcosa di insolito.