Esistono giustificazioni per lasciare gli indicatori di conflitto nel codice archiviato?

Prendi in considerazione i marker di conflitto. vale a dire:

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

Nel caso particolare che mi ha motivato a pubblicare questa domanda, il membro del team responsabile aveva appena completato una fusione a monte della nostra filiale e in alcuni casi li aveva lasciati, come commenti, come una sorta di documentazione su ciò che era appena stato risolto. Lo ha lasciato in uno stato compilato, i test passano, quindi non è così male come si potrebbe pensare.

Istintivamente, però, ho davvero sollevato obiezioni a questo, ma essendo i diavoli sostenitori di me stesso posso vedere perché avrebbe potuto farlo:

• perché evidenzia agli altri sviluppatori del team ciò che è cambiato a seguito della fusione.
• perché coloro che sono più esperti con particolari parti di codice possono quindi affrontare le preoccupazioni illustrate dai commenti in modo da non dover indovinare.
• perché l'unione a monte è una sofferenza giusta e può essere difficile giustificare il tempo per risolvere tutto bene e completamente, quindi è necessario un avviso FIXME semi-completo, quindi perché non usare il conflitto originale come commento per documentarlo.

La mia obiezione era istintiva, ma mi piacerebbe essere in grado di giustificarla razionalmente, o di vedere la mia posizione più saggiamente. Qualcuno può darmi alcuni esempi o anche esperienze in cui le persone hanno avuto un brutto momento con qualcun altro che fa questo e / o motivi per cui è una cattiva pratica (o puoi fare da avvocato del diavolo e supportarlo).

La mia preoccupazione immediata era che sarebbe stato chiaramente fastidioso se avessi modificato uno dei file interessati, tirato le modifiche, ottenuto conflitti reali, ma anche inserito quelli commentati. Quindi avrei davvero avuto un file molto disordinato. Fortunatamente ciò non è accaduto.

Questo è chiaramente sbagliato. È compito del sistema di controllo della versione tenere traccia delle modifiche ed è compito degli strumenti diff mostrare ciò che è cambiato a seguito della fusione. Dovrebbe esserci un commento nel registro di commit, e forse nel codice, che spiega cosa è stato modificato e perché. Tuttavia, IMHO, lasciando gli indicatori di conflitto come commenti equivale a lasciare in giro il codice morto.

Ho avuto un problema simile con un codice che è stato commentato (che è in qualche modo simile al tuo caso) o spostato in un metodo che non viene effettivamente chiamato da nessuna parte. Alla domanda sul perché le persone lo fanno, la risposta è che si sentono un po 'più sicuri quando hanno ancora qualche blocco di codice. L'argomentazione più ovvia è che si tratta del lavoro VCS e non del loro. Tuttavia, c'è anche un altro aspetto. Quando qualcun altro legge il codice mentre apprende o apporta modifiche, sarà probabilmente seguito da un tale commento. Lo leggerà sicuramente e forse passerà un po 'di tempo a capire perché è qui e quale possibile correlazione ha con il suo attuale lavoro. Poiché un indicatore di conflitto è un segno di un conflitto, che è già stato risolto, questo è sicuramente una perdita di tempo.

Penso che i commenti dovrebbero fare riferimento al codice che è lì, non al codice che è stato lì in passato, né agli eventi accaduti al codice qualche volta in passato, né al codice che esisteva in un universo parallelo (un altro ramo) nel passato. Lasciare i marcatori come hanno fatto i membri del tuo team crea almeno tre problemi:

1. Il codice originale probabilmente era qualcosa di simile blah blah null , e la segnalazione di bug diceva "Non è possibile utilizzare null lì, utilizzare questo o quello, o altro". Quindi due persone hanno risolto il bug in modo indipendente e quando le correzioni sono state unite, il conflitto è sorto. Ora il commento non documenta quale sia stato il problema né quale sia stata la correzione, ma solo che in passato sono state apportate due diverse correzioni. Non è molto utile. Un commento del genere //blah blah needs a non-null argumentdarebbe almeno un'indicazione di ciò che è cambiato (e anche che le informazioni sono più facilmente disponibili dal commento di commit del sistema di controllo della versione).
2. La versione unita potrebbe non apparire nemmeno come una delle linee originali. Forse se vuoi che bla bla prenda questo e quello, la forma corretta èblah blah (this,that) o anche qualcosa di più complicato. In tal caso, lasciare il messaggio di conflitto come commento confonderà sicuramente chiunque provi a leggere il codice in un secondo momento.
3. La maggior parte dei sistemi di controllo versione consente di accedere alla cronologia del progetto. Ad esempio, posso fare clic con il tasto destro su un file in eclipse (con svn), dire "Mostra cronologia ..." e poi dire "Confronta corrente con ..." e ottenere una finestra diff che evidenzia le differenze. più facile da individuare se i punti salienti del diff contengono le differenze effettive e non i commenti che li circondano. Ogni piccola modifica non funzionale del codice rende la differenza più difficile da leggere.

Quanto sono fastidiosi gli indicatori di conflitto nel codice archiviato?

Così fastidioso.