I commenti di TODO hanno senso? [chiuso]

Tendo ad usare // todo commenti per cose che hanno , ma non posso farlo immediatamente.

Inoltre mi assicuro di inseguirli - li cerco (Visual Studio ha una bella funzionalità in cui elencherà tali commenti per te) e assicurerà che le cose siano fatte.

Ma, come dici tu, non tutti sono diligenti su di loro e come molti commenti, tendono a marcire nel tempo.

Direi che questa è più una preferenza personale - finché si documenta ciò che deve essere fatto e si insegue su di esso, non importa se è in // todo , postit note o una lavagna (dove possono anche finire per non essere stati attivati).

Gli IDE moderni riconoscono i commenti di TODO e sono così visibili nel proprio pannello / finestra / tab, quindi non sono teoricamente persi (penso a Eclipse e Visual Studio, entrambi so abbastanza per ricordare che essi riconoscilo).

È anche possibile configurare parole di commento aggiuntive come FIXME , BEWARE o qualsiasi altra cosa che si desidera personalizzare. Tuttavia, altri sviluppatori del tuo progetto dovranno personalizzare il loro IDE allo stesso modo.

Ora, ho scritto "teoricamente" perché sebbene non sia stato perso, TODO si riferisce spesso a qualcosa che non è necessario affinché l'applicazione funzioni correttamente "al momento". E "al momento" può estendersi per 5 minuti a 5 anni, a seconda del tipo / dimensione del progetto: -)

Infine, a mio parere, ha ancora più senso averli nel codice, nel posto giusto, rispondendo precisamente alla domanda "dove dovrei apportare la modifica" piuttosto che altrove al di fuori del codice.

Modifica: come è scritto nell'articolo di Wikipedia sui commenti di Wikipedia, inclusi la data e il proprietario del TODO è considerato una buona pratica.

Potrebbe avere un senso, almeno a volte li uso. Il punto chiave è usare tag coerenti come TODO o FIXME in modo che possano essere trovati facilmente con una semplice ricerca testuale.

Ad esempio, le soluzioni "veloci" e "sporche" sono convenienti per l'etichetta, ad esempio:

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

Se il codice fa quello che deve fare e nessuno si lamenta, il commento non fa male. Se c'è ancora tempo per abbellire il codice, è facile iniziare con la ricerca delle etichette FIXME .

Nel mio settore, gli sviluppatori sono incoraggiati a inserire le voci JIRA (o etc) invece dei commenti di todo perché non tutti hanno la possibilità di vedere le voci // todo . Ma a volte nei grandi progetti un attributo personalizzato viene definito sulla falsariga di:

[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
    public DateTime EntryDate { get; set; }
    public string Description { get; set; }
    public DeveloperNote(int year, int month, int day, string desc)
    {
        EntryDate = new DateTime(year, month, day);
        Description = desc;
    }
}

E quindi un metodo può essere decorato in questo modo ...

[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]

E i più alti possono arrivare e raccoglierli automaticamente. Potrebbe essere eccessivo per il semplice promemoria // todo , ma è efficace. Inoltre richiede una piattaforma .NET.

Secondo la mia esperienza dipende Il fattore principale è se la squadra è abbastanza disciplinata da seguire questi "piccoli" commenti. Se lo fanno allora sì, hanno senso. In caso contrario, questi commenti sono solo una perdita di tempo e potresti voler esaminare altre opzioni, ad es. story card.

Personalmente uso i commenti di TODO occasionalmente, ma di solito sono di breve durata e di solito ne ho solo un numero molto piccolo come uno, due o tre. Li uso più come marcatore nella base di codice di qualsiasi altra cosa. Se aspetto troppo tempo per prendermi cura di loro, dimentico ciò che pensavo di aver bisogno di "fare".

La mia preferenza sarebbe sempre quella di non usarli e invece usare le story card o gli arretrati o simili. Utilizza un meccanismo per un'attività.

TODO è solo una sottomaschera di commenti. I commenti hanno una grande utilità se lo scrittore è del tutto esperto nel sapere cosa trasmettere e come trasmetterlo. Un senso dell'umorismo può anche essere applicato qui in piccole dosi per deliziare i manutentori anni dopo.

Ho ricevuto una chiamata l'anno scorso che parte del mio codice era in pensione. Sono rimasto piuttosto colpito dal fatto che fosse stato in produzione e sopravvissuto alla manutenzione per 16 anni. Quindi, tieni presente che il tuo codice potrebbe durare molto. I commenti su intenzioni, esigenze future e così via possono aiutare molto qualcuno per anni che guarda il tuo codice per la prima volta.

In passato li scrivevo in passato, ma ho scoperto che di solito non li segui.

Quindi ora li uso solo per contrassegnare le cose su cui voglio lavorare subito dopo aver finito quello con cui sono impegnato. Ad esempio, implemento una nuova funzione e noto che una funzione che utilizzo ha un piccolo bug; Faccio un FIXME per risolvere questo problema per evitare di essere deragliato nel mio attuale compito.

Per aiutarmi, le nostre build CI sono configurate in modo da fallire se ci sono FIXME nel codice: -).

Se noti potenziali problemi che non possono essere risolti immediatamente, apri un ticket / bug / problema per loro. In questo modo, possono avere la priorità come tutti i bug. Ritengo che sia molto meglio che avere alcuni problemi nel DB degli errori e alcuni nel codice come TODO.

Se lo desideri, puoi inserire un TODO con l'ID del bug: -).

Penso che i commenti di TODO , in una certa misura, abbiano senso. Soprattutto se stai lavorando in modo iterativo (come è comune nei negozi di TDD e agili), ci saranno cose in cui riconoscerai che saranno necessari in breve tempo ma a cui non vuoi fare la deviazione per implementare giusto allora e lì.

Ciò che diventa brutto è quando tali commenti rimangono nella base di codice. Mentre stai lavorando attivamente su una funzione, è meglio lasciarli, ma non appena ti avvicini al completamento della funzione, dovresti concentrarti su come eliminarli. Se non si vuole passare attraverso il lavoro di rimpiazzarli effettivamente con un codice corretto e funzionante, almeno, si deve tener conto della funzionalità pertinente. Per prendere in prestito l'esempio di @ JoonasPulakka, dove inizialmente il codice dice

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

potresti cambiarlo in qualcosa di simile

ConnManager.getConnection(GetDatabaseName());

con, al momento, GetDatabaseName () è uno stub che restituisce semplicemente la stessa stringa con cui hai iniziato. In questo modo, c'è un chiaro punto di espansione futura, e tu sai che qualsiasi modifica fatta lì si rifletterà ovunque sia necessario il nome del database. Se il nome del database è anche moderatamente generico, questo può essere un notevole miglioramento della manutenibilità.

Personalmente, io uso una mia parola chiave invece che rigorosamente TODO , sebbene l'intento sia lo stesso: marcare cose che so che avranno bisogno di rivedere. Inoltre, prima di controllare il mio codice, eseguo una ricerca di codice sorgente globale per quella parola chiave, che viene scelta in modo tale che normalmente non dovrebbe apparire in nessuna parte del codice. Se viene trovato, so che ho dimenticato qualcosa e posso andare avanti e correggerlo.

Come per includere il nome / firma del programmatore con il commento, penso che sia eccessivo se hai un sistema di controllo della versione del codice sorgente (tu fai , giusto?). In tal caso, la sua caratteristica di colpa ti dirà chi ha aggiunto il commento o, più precisamente, chi ha effettuato l'ultimo controllo in una modifica che ha toccato il commento. Ad esempio, in Visual Studio, ciò si ottiene facilmente utilizzando la funzione "Annotazione" che si trova tra le funzioni di controllo del codice sorgente.

Di solito non faccio // i commenti di TODO ma li tengo tutti in un file separato. Non riesco ancora a trovare / scrivere software online per gestirli facilmente in modo che i file TODO siano ancora più utili per me perché quando apro il progetto dopo un po 'di tempo dimentico cosa fare ora e poi guardo il file TODO e faccio il lavoro . Ho "filename.cpp 354: Ricodifica questo bla bla bla" ed è molto più utile quindi cerca // TODO commenta nel file. Ho fatto // TODO earler quando ero pigro ma rimuovo quei vecchi // TODO-s dal file sorgente e non li aggiusto quando il progetto funziona bene. Consiglio vivamente di spostare tutti i // TODO dalla souce in un posto separato e tenerli insieme ad altri ancora, in modo da rendere più semplici le attività. La priorità è TODO davvero difficile quando hai tutti i tuoi TODO in vari file e vari progetti.

Penso che ci sia un grande, ma non solo. Ad esempio:

//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice

Questo approccio funziona con parsimonia. Anche se dovrei dire che prendere l'abitudine di lanciare eccezioni per ricordarti di completare un codice non è l'approccio più professionale. Ma mi ha salvato in alcuni casi in cui pensi di aver completato qualcosa e persino di averlo scritto quando non lo hai fatto.

Se scrivi un TODO o FIXME con l'idea che qualcun altro lo aggiusterà quando arriveranno a quel codice in un futuro indeterminato, allora direi di non preoccuparti. Dissotterreranno il codice e ingombreranno la parte di segnalazione del tuo IDE che raccoglie queste informazioni.

Per essere utili dovrebbero fornire un mezzo per contrassegnare il tuo codice per il (molto) prossimo futuro in modo da poter tornare in uno stato mentale adeguato più velocemente. In altre parole, li inserisci nel tuo codice solo per rimuoverli al più presto.

Qualunque cosa vissuta più a lungo dovrebbe in effetti essere collocata nella tua base di bug a cui appartiene.

C'è abbastanza rumore nelle nostre vite, non creiamo una nuova fanfara di cose che urlano attenzione mentre è richiesto altrove.

Il mio 2 cent

L'enorme vantaggio dei commenti di todo su uno qualsiasi degli altri milioni di modi in cui è possibile creare un elenco di attività è che i commenti di viaggio viaggiano con il codice in modo che non possano essere separati.

Probabilmente il posto più appropriato per cose come questa è il tracker dei problemi piuttosto che il codice.

Raccomando vivamente di inserire TODO o FIXME in un log formale. Se non lo sono, sono facilmente ricercabili e dovrebbe essere una fase di ogni iterazione per controllare TODO e FIXME in sospeso. Questi possono quindi essere catalogati e impostati per un rimedio immediato oppure il team può pianificare di risolverli al momento opportuno.

Infine, una volta risolti devono essere rimossi - se non vengono eliminati in modo sistematico dopo essere stati risolti, perderanno la loro efficacia.

In conclusione: sono migliori dei problemi di registrazione, ma in realtà devi mantenerli.

IntelliJ ti avviserà in realtà se tenti di eseguire il commit del codice con nuovi TODO. Quindi, puoi sempre interpretare un TODO come "questo dovrebbe accadere davvero al momento del commit".

Se consideri il "TODO" come un'etichetta semantica per il tuo commento, penso che abbia senso.

Negli standard di codifica della mia azienda, specifichiamo che le iniziali dello sviluppatore responsabile devono essere incluse con il TODO ( i.e. , vorrei digitare "SAA TODO:"). Penso che questo sia utile, almeno come una convenzione, perché altrimenti c'è la tentazione di lasciare codice scadente con la nota TODO per lo sviluppo di qualche futuro sviluppatore.

Sicuramente, molti IDE possono essere configurati per aggiungere questi commenti a un elenco di attività, consentendo loro di essere trattati allo stesso modo per creare conflitti e non essere dimenticati indefinitamente.

Un metodo più odioso, ma efficace, è probabilmente quello di trasformare i tuoi commenti Todo in messaggi del compilatore, in modo tale che tu e tutti gli altri lo vedano quando il programma è compilato.

in Delphi:

{$message 'todo: free this thing when you know its not going to blow up'}

Nella mia esperienza, TODO dovrebbe essere usato per indicare che un pezzo di codice è non utilizzabile e dice al lettore cosa è necessario renderlo utilizzabile (localmente o altrove).

TODO non devono essere utilizzate per indicare che una parte di codice sarebbe più bella se modificata in qualche modo. Gli esempi includono il codice dirty che sarebbe più mantenibile se riscritto o una funzionalità aggiuntiva di cui nessuno ha ancora bisogno. Queste annotazioni si accumulano e fanno in modo che% co_de restituisca risultati inutili.