Commenti sul numero di bug

https://stackoverflow.com/questions/163232

03-07-2019
|

Domanda

Perché dovresti aggiungere

// Bug 1024

commenti in una base di codice controllata dalla fonte? La maggior parte dei sistemi di tracciamento dei bug e controllo del codice sorgente sono meglio equipaggiati per tenere traccia di queste informazioni. Nel controllo del codice sorgente, è possibile utilizzare un'etichetta o un commento con il check-in. In un bug tracker il numero di revisione può essere aggiunto alla risoluzione del bug. Quindi perché commentare il codice? Particolare in quanto la rilevanza di questi commenti ha una durata molto breve e tende a accumularsi nella base di codice.

Soluzione

Ne ho trovato uno utile l'altro giorno nella nostra base di codici.

Ho detto " perché sta chiamando la funzione di inizializzazione una seconda volta, fino a tardi nel flusso di lavoro ?? "

Il commento sul bug mi lascia andare a destra nella descrizione del problema. Quando ho ritoccato il codice, ero sicuro di includere quel bug nei miei test e non lo ho reintrodotto.

Anche se dirò che in generale sono d'accordo con te e non inserisco me stesso.

Avrei preferito che lo sviluppatore in questione correggesse il bug in modo più significativo, in modo da non dover prima chiedermi il codice.

Altri suggerimenti

In definitiva, penso che sia una cattiva pratica. È meglio includere perché esiste il bug (i foo di tipo Y non hanno la proprietà Z). Puoi includere un "altro in BugId 12345" insieme a quello se vuoi.

Se ti stai integrando su più livelli, una vista del codice sorgente in trac può collegarsi direttamente a BugId.

Pigrizia pura. Certo, ci vuole più tempo a lungo termine, ma a breve termine "Bug 1024" non fa alcuno sforzo. Più codice hai, peggio è.

Immagina di avere un nuovo bug da rintracciare fino alla modifica nella revisione 12345. Dai un'occhiata ai log e ti dice immediatamente che il bug 1024 è stato il motivo per cui è stata apportata la modifica.

Puoi quindi andare a vedere 1024 per vedere cosa, perché e quando prima di fare una nuova correzione - quella per dominarli tutti.

Se il numero del bug non è presente nel messaggio di commit, è necessario cercare il bug risolto da un commit e che potrebbe essere diverso (se il bug viene segnalato più di una volta).

Penso che questo sia un caso di "Ho un martello, che deve essere un chiodo". Il tuo editor di testo o IDE non è l'unico strumento per la gestione del codice.

La cronologia viene gestita al meglio esternamente al codice. Il significato del codice dovrebbe essere descritto nei commenti quando non immediatamente evidente.

Sono d'accordo che i numeri di bug dovrebbero essere nei messaggi di commit del controllo del codice sorgente.

Non dovresti mai aggiungere solo il numero di bug. È necessario aggiungere il numero di bug, l'oggetto e tutti i qualificatori se sono stati effettuati più check-in per un singolo bug:

Bug 1111 - Foo eliminato su sistemi a 64 bit. Correzione n. 2 perché è stato riaperto dopo l'unione al trunk.

Alcuni sistemi hanno l'integrazione del numero di bug. In mxr.mozilla.org il numero di bug nella visualizzazione del registro cvs viene automaticamente magicamente trasformato in un collegamento al numero bugzilla.mozilla.org. Quando stai scavando nel codice, questo è un enorme risparmio di tempo. Penso che Fogbugz abbia una funzione simile ...

Inoltre, anche se il tuo sistema non lo fa, spesso aiuta perché nessuno vuole vedere l'intero contesto della modifica nei commenti, questo è lo scopo del bug tracker.

Concordo con te sul fatto che il commento in questo modo non è davvero utile ed è troppo breve.

È tuttavia estremamente utile e importante commentare il codice con riferimenti ai record nel sistema di tracciamento dei difetti (o in questo modo estendere a qualsiasi repository KM che potresti avere).

A volte un codice viene modificato per implementare una soluzione alternativa a un determinato problema con il comportamento dell'applicazione. A volte la soluzione alternativa introdotta non è in alcun modo logica. Accade spesso che quando un codice viene aggiornato da qualcun altro, questo "cattivo" pezzo di codice viene rimosso come parte dello sforzo di re-factoring.

Pertanto, contrassegnare un codice come appartenente a una particolare correzione di bug lo rende visibile durante il factoring, spingendo lo sviluppatore a rivedere la descrizione del bug prima di modificare il codice. Aiuta anche nella situazione in cui il bug viene riaperto: se devi cambiare la stessa parte del codice più volte potresti considerare di investire tempo in una soluzione alternativa.

P.S. potresti ritenere utile questo articolo su MS Office di Joel On Software. Per quanto ne so il codice di MS Office e MS Windows è pieno di commenti simili che spiegano le decisioni prese dagli sviluppatori da tempo.

Lo trovo utile quando si spiega codice che altrimenti sembrerebbe sbagliato, e anche per l'uso nei messaggi di commit.

Non lo faccio. Non riesco a pensare a una buona ragione per cui si dovrebbe inserire l'ID difetto nel codice. Lo inserirò invece nelle note di rilascio / log delle modifiche.

Quello che trovo utile è usare l'ID difetto come parte del nome nei test automatici:

[TestFixture]
public class Release_1_2_Bugfixes
{
  [Test]
  public void TestBug42()
  {
    Assert.AreEqual(42, CalculateAnswerToLifeUniverseAndEverything());
  }
}

Ho visto altri progetti fare la stessa cosa.

Sono sorpreso da quante persone si oppongono a questo. La mia sensazione personale è che si tratta di un'idea molto buona . Concordo con un commento precedente che dovrebbe includere più del semplice numero di bug e, preferibilmente, includere un breve sommario e un collegamento al sistema di tracciamento dei bug, se appropriato.

Il vantaggio di questi commenti è evidente solo in un vecchio progetto con cronologia e un gran numero di correzioni di bug precedenti. Non è necessario rendere questi commenti ovunque, ma sono molto utili se inseriti davanti a un blocco di codice che potrebbe non avere senso senza contesto. In qualsiasi tipo di sistema ragionevolmente complesso, ci saranno frammenti di codice che sembrano illogici o inutili senza contesto.

A causa di interazioni con il sistema o di vecchie soluzioni alternative, il codice è necessario. Al fine di impedire a qualcuno in seguito di reintrodurre un bug corretto, è estremamente utile indicare il bug che il blocco di codice è progettato per risolvere, preferibilmente con qualche tipo di spiegazione allegata. Altrimenti dipendi da qualcuno che controlla attentamente la cronologia di commit per un motivo registrato nel registro di commit, il che è altamente improbabile, specialmente se qualcuno sta eseguendo il refactoring del codice.

MODIFICA : mi riferisco specificamente a inserirli con un blocco di codice insolito o che necessita del contesto aggiuntivo. Non è utile o necessario commentare ogni singola correzione di errore che fai :-)

L'ho fatto fino a quando Visual Studio 2008 non è stato spedito con annotazione. È stato utile quando si guardava indietro al vecchio codice per vedere immediatamente che almeno si pensava dietro una particolare decisione sul codice.

Sì, lo so che puoi fare un confronto con le versioni precedenti, ma è un tale dolore nel culo quando hai solo bisogno di sentirti bene con gli aggiornamenti minori del codice.

Se stai navigando attraverso un codice sorgente sconosciuto e vedi qualcosa di non visibile, è bello conoscerne il motivo. Si tratta tuttavia di un giudizio, non tutte le correzioni di bug hanno bisogno di una tale spiegazione - probabilmente la maggior parte può cavarsela senza di essa.

Se c'è abbastanza motivo per credere che qualcuno vorrebbe conoscere il numero del bug quando si guarda una parte del codice, aggiungere un commento che menziona il bug può essere abbastanza bello (si spera che possa parafrasare anche i bit importanti del bug, tuttavia).

Sì, i messaggi di commit del controllo del codice sorgente dovrebbero contenere anche i numeri di bug e la ricerca nei registri di revisione può darti le stesse informazioni ... ma se la stessa parte del codice viene cambiata più volte, ma i dettagli appresi dal il bug iniziale si applica ancora, potrebbe essere necessario un po 'di tempo per trovare la modifica originale per conoscere il bug.

Inoltre, si verificano situazioni in cui vi è una buona ragione per spostare il codice da una classe all'altra o per rinominare i file, il che renderebbe ancora più difficile trovare la radice del motivo dietro una certa sezione di codice (rinominare non così molto un problema con SVN, ma un dolore con CVS).

Hai colpito l'unghia sulla testa con "la pertinenza ha una vita molto breve e tendono ad accumularsi sporcando la base di codice." "

Ogni frammento inutile che si accumula nei file sorgente li rende un po 'meno leggibili e difficili da mantenere. Elimina tutto ciò che non aggiunge valore. " Bug 12345 " ha poco valore ora e non ne avrà nessuno tra poche settimane.

Lavoriamo su un sistema su larga scala con molti sviluppatori e più filiali rilasciate.

Questi commenti di riferimento di bug possono effettivamente essere molto utili durante il porting da un ramo all'altro, specialmente perché il sistema SCM che usiamo è molto povero di funzionalità e i commenti di commit sono difficili da ottenere o potrebbero essere piuttosto vecchi.

Se la correzione fosse semplice, potrebbe non essere necessario un marcatore di bug. Se non è ovvio, potrebbe essere più sensato fare riferimento a un bug, quindi scrivere una lunga spiegazione in una sezione di commento.

Non mi piace questo tipo di graffiti. Come altre forme di vita sgradevoli che si accumulano nel tempo, soffocando la base di codice.

Il problema inizia davvero quando le persone apportano correzioni di bug che si sovrappongono a una precedente correzione di bug. Quindi hai numeri di bug che etichettano una sezione di codice che sono semplicemente sbagliati o fuorvianti.

Questo tipo di commento È molto utile: cosa succede quando si cambiano gli strumenti di tracciamento dei bug o di controllo del codice sorgente? Un riferimento a BZ1722 vs FB3101 ti dirà quale strumento di monitoraggio controllare (Bugzilla o FogBugz per esempio).

È una buona cosa!

È improbabile che la persona che sta guardando il codice apprezzi la cronologia completa del codice ed è probabile che annulli una modifica molto importante perché potrebbe non aver mai lavorato in questa area del codice prima. Può spiegare il codice che altrimenti sembra folle o un requisito del cliente che è altrettanto bizzarro.

Non puoi sempre catturare i minimi dettagli dei requisiti dei clienti attraverso l'architettura e il codice, specialmente quando chiedono qualcosa di stupido. Quindi inizi con il sensibile e poi raffini o incidi il codice nello stupido quando sei costretto a farlo, i numeri dei bug confermano l'intento del codice pazzo.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow