Unica dichiarazione non rinforzata e codice unito [duplicato]

Penso che la condizione di cui stanno parlando sia questa

Cambia 1 (aggiungi, riga 20-21):

if (condition)
    doSomeStuff();

Cambia 2 (aggiungi, riga 20-21):

if (condition)
    doOtherStuff();

Scommetto che qualche vecchio strumento di auto-fusione da qualche parte proverebbe ad essere intelligente e dire "beh, hai entrambi aggiunto la stessa linea due volte a 20, quindi lo aggiungerò una volta, e hai aggiunto due linee diverse a 21, quindi le aggiungerò entrambe. " Che porta a

if (condition)
    doSomeStuff();
    doOtherStuff();

Questi argomenti storici tendono ad aggirarsi molto dopo che ogni strumento di unione sul pianeta è stato risolto per funzionare in modo diverso.

Qualsiasi auto-fusione che abbia mai visto rifiuterebbe di unire due aggiunte nello stesso posto, il che significa che devi usare uno strumento di unione manuale. Nel peggiore dei casi, potrebbe aggiungerne uno prima dell'altro, che è ancora valido. Ma uno strumento di unione decente ti permetterà di modificare questo posto e finire con

if (condition) {
    doSomeStuff();
    doOtherStuff();
}

Hai ragione, e non si romperà nel modo descritto. A meno che tu non stia usando uno strumento di fusione davvero pessimo, lo scenario che descrivi non dovrebbe accadere. Gli strumenti di unione non inseriscono magicamente il codice che non esiste nella versione nuova o vecchia del file.

Il vero problema è che i programmatori sono molto più adatti ad estendere la logica all'interno di un condizionale e dimenticare di aggiungere le parentesi. Non è un problema di strumento di unione, è un problema di persone. E mi considero in quel campo dopo aver fatto quell'errore prima.

Se tutti i condizionali a linea singola devono essere racchiusi tra parentesi graffe è un sottotema all'interno delle guerre sante dello stile del codice. Ciò che è giusto può essere deciso dal tuo team solo per il tuo team.

La tua squadra deve prendere una decisione su ciò che vuole e inserirla nelle linee guida dello stile di codifica.

È così facile rompersi in un modo che non ti accorgerai quando si rompe.

 if (condition)
     doSomeStuff(A);

 // Code

Sulla base di un vero cambiamento ho visto un nuovo acquisto:

-    void doSomeStuff(int A)
-    {
-        Action1(A);
-        Action2(A);
-        Action3(A);
-    }
+    // I modified this function to a macro to make sure it inlines and
+    // thus we get s speed increase due to decreased functions calls.
+    #define doSomeStuff(A)        Action1(A);       \
+                                  Action2(A);       \
+                                  Action3(A);

Sì, è una situazione stupida che non farà ciò che dicono i commenti. Ma le persone fanno ogni sorta di supposizioni e cambieranno il codice in base a queste ipotesi. E facilmente rompere il codice.

E non vedrai mai nei punti di utilizzo che è rotto fino a quando non è troppo tardi.

Così mi costringo abitualmente a usare sempre le bretelle.

L'unica cosa che mi viene immediatamente in mente, è il tipico problema di uno sviluppatore che crede che la sua affermazione sia ancora parte della condizione quando è al di fuori della condizione, quindi viene eseguita la loro istruzione condizionale. L'ho visto più e più volte.

Esempio

if (condition)
    do something in condition;
    do something else in condition; // Outside the condition always gets run

So che non è direttamente correlato alla tua domanda, ma se stai facendo un merging automatico dei codici questo è il tipo di cosa che potrebbe intrufolarsi più spesso. doppiamente così se non stai testando correttamente per le interruzioni prima dell'unione.

Per questa ragione ritengo che sia una buona politica essere più espliciti con il tuo rinforzo condizionato e molto di più se stai facendo unioni automatiche. Spero anche che con ogni unione ci sia una serie di test da eseguire per garantire che le unioni siano riuscite e l'applicazione funzioni come previsto.