Esiste una giustificazione per lasciare indicatori di conflitto nel codice di accesso?

14

Considera i marcatori di conflitto. cioè:.

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

Nel caso particolare che mi ha motivato a postare questa domanda, il membro del team responsabile aveva appena completato una fusione da upstream alla nostra filiale, e in alcuni casi li aveva lasciati, come commenti, come una sorta di documentazione su cosa era appena stato risolto. Lo ha lasciato in uno stato compilato, testando il passaggio, quindi non è così male come si potrebbe pensare.

Però istintivamente, ho davvero preso obiezioni a questo, tuttavia essendo diabolico difendere a me stesso posso capire perché avrebbe potuto farlo:

  • perché evidenzia agli altri sviluppatori del team cosa è cambiato in seguito all'unione.
  • perché chi è più esperto con i pezzi di codice specifici può quindi risolvere le preoccupazioni illustrate dai commenti in modo che non debba indovinare.
  • perché l'unione upstream è un dolore giusto e può essere difficile giustificare il tempo necessario per risolvere tutto correttamente e completamente, quindi è necessario un avviso FIXME semi-completo, quindi perché non utilizzare il conflitto originale come commento per documentare questo .

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

La mia preoccupazione immediata era che sarebbe stato sicuramente fastidioso se avessi modificato uno dei file in questione, tirato le modifiche, ottenuto veri conflitti, ma inserito anche quelli commentati. Quindi avrei davvero avuto un file davvero disordinato. Fortunatamente non è successo.

    
posta Benedict 25.10.2011 - 19:38
fonte

4 risposte

27

Questo è chiaramente sbagliato. È compito del sistema di controllo delle versioni tenere traccia dei cambiamenti, ed è compito degli strumenti diff per mostrare cosa è cambiato in seguito all'unione. Ci dovrebbe essere un commento nel registro di commit e forse nel codice, che spiega cosa è stato cambiato e perché. Tuttavia, IMHO, lasciando i marcatori di conflitto come commenti è lo stesso di lasciare il codice morto intorno.

    
risposta data 25.10.2011 - 20:04
fonte
5

Ho avuto un problema simile con alcuni codici che venivano commentati (che in qualche modo sono simili al tuo caso) o spostati su un metodo che non viene effettivamente chiamato da nessuna parte. Alla domanda sul perché le persone facciano questo, la risposta è stata che si sentono un po 'più al sicuro quando hanno ancora un blocco di codice. L'argomento più ovvio è che è un lavoro VCS e non il loro. Tuttavia, c'è anche un altro aspetto. Quando qualcun altro sta leggendo il codice mentre impara o apporta modifiche, verrà probabilmente messo di fianco a tale commento. Lo leggerà sicuramente e forse passerà un po 'di tempo a capire perché è qui e quale correlazione possibile ha con il suo attuale lavoro. Poiché un indicatore di conflitto è un segno di un conflitto, che è già stato risolto, è sicuramente una perdita di tempo.

    
risposta data 25.10.2011 - 21:20
fonte
4

Penso che i commenti dovrebbero riferirsi al codice che è lì, non al codice che è stato lì nel passato, né agli eventi accaduti al codice qualche volta nel passato, né al codice che esisteva in un universo parallelo (un altro ramo ) nel passato. Lasciando i marcatori nel modo in cui il tuo membro del team ha creato almeno tre problemi:

  1. Probabilmente il codice originale era qualcosa come blah blah null , e il bug report diceva "Non posso usare null lì, usa questo o quello, o qualsiasi altra cosa". 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 fosse il problema, né cosa risolvesse la correzione, ma solo che ci sono state due correzioni diverse ad un certo punto nel passato. Non è molto utile. Un commento come //blah blah needs a non-null argument fornirebbe almeno un'indicazione su cosa è cambiato (e anche quell'informazione è più facilmente disponibile dal commento di commit del sistema di controllo della versione).
  2. La versione unita potrebbe non sembrare nemmeno una delle linee originali. Forse se vuoi che bla bla faccia 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 sicuramente confonderà chiunque provi a leggere il codice in seguito.
  3. La maggior parte dei sistemi di controllo delle versioni ti dà accesso alla cronologia del progetto. Ad esempio, posso fare clic con il pulsante destro del mouse su un file in eclissi (con svn), pronunciare "Mostra cronologia ..." e quindi pronunciare "Confronta corrente con ..." e ottenere una finestra di confronto che evidenzi le differenze. più facile da ingannare se i punti salienti del differenziale contengono le differenze effettive e non i commenti che li circondano. Ogni bit di modifica non funzionale nel codice rende difficile la lettura.
risposta data 26.10.2011 - 15:16
fonte
-1

How annoying are conflict markers in checked-in code?

Quindi fastidioso.

    
risposta data 26.10.2011 - 18:29
fonte

Leggi altre domande sui tag