I commenti di TODO hanno senso? [chiuso]

Sto lavorando a un progetto abbastanza grande e ho il compito di fare alcune traduzioni per questo. C'erano tonnellate di etichette che non sono state tradotte e mentre cercavo il codice ho trovato questo piccolo pezzo di codice

//TODO translations

Questo mi ha fatto pensare al senso di questi commenti per te (e gli altri?) Perché ho avuto la sensazione che la maggior parte degli sviluppatori dopo aver fatto un certo pezzo di codice e fa quello che dovrebbe fare non lo guardano mai fino a quando non hanno per mantenerlo o aggiungere nuove funzionalità. In modo che questo TODOandrà perso per molto tempo.

Ha senso scrivere questi commenti o dovrebbero essere scritti su una lavagna / carta / qualcos'altro in cui rimangono al centro degli sviluppatori?

Tendo a usare i // todocommenti per le cose che devono accadere, ma non posso farlo immediatamente.

Mi assicuro anche 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 - fintanto che documenti ciò che deve essere fatto e lo insegui, non importa se è dentro // todo, invia note o una lavagna (dove possono anche finire in azione).

Gli IDE moderni riconoscono i TODOcommenti e sono come tali visibili nel proprio pannello / finestra / scheda, quindi teoricamente non vengono persi (sto pensando Eclipse e Visual Studio, entrambi conosco abbastanza per ricordare che lo riconoscono).

È anche possibile configurare ulteriori commento parole come FIXME, BEWAREo qualsiasi altra cosa che si desidera personalizzare. Tuttavia, altri sviluppatori del tuo progetto dovranno personalizzare il proprio IDE allo stesso modo.

Ora, ho scritto "teoricamente" perché, sebbene non perso, TODO si riferisce più che spesso a qualcosa che non è necessario per il corretto funzionamento dell'applicazione "al momento". E "al momento" può durare da 5 minuti a 5 anni, a seconda del tipo / dimensione del progetto :-)

Infine, a mio avviso, ha ancora più senso averli nel codice, nel posto giusto, rispondendo esattamente alla domanda "dove dovrei fare la modifica" rispetto a qualche altra parte al di fuori del codice.

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

Può avere un senso, almeno li uso a volte. Il punto chiave è usare tag coerenti come TODOo FIXMEcosì che possano essere facilmente trovati con una semplice ricerca di testo.

Ad esempio, le soluzioni "quick 'n dirty" sono comode da etichettare, come:

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

Se il codice fa quello che dovrebbe fare e nessuno si lamenta, allora il commento non fa male. Se c'è mai tempo per abbellire il codice, è facile iniziare con la ricerca di FIXMEetichette.

Nel mio settore, gli sviluppatori sono incoraggiati a inserire voci JIRA (o ecc.) Invece di fare commenti perché non tutti hanno la possibilità di vedere le // todovoci. Ma a volte nei progetti di grandi dimensioni un attributo personalizzato viene definito sulla base 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 rialzi più alti possono arrivare e raccoglierli automaticamente. Potrebbe essere eccessivo per il semplice // todopromemoria, ma è efficace. Inoltre richiede una piattaforma .NET.

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

L'anno scorso ho ricevuto una telefonata per ritirare parte del mio codice. Sono stato piuttosto colpito dal fatto che fosse stato in produzione e sia sopravvissuto alla manutenzione per 16 anni. Quindi fai attenzione, il tuo codice potrebbe durare molto a lungo. Commenti su intenzioni, esigenze future e così via possono fare molto per aiutare qualcuno da anni a guardare il tuo codice per la prima volta.

Nella mia esperienza dipende. Il fattore principale è se la squadra è abbastanza disciplinata per dare seguito a 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 esempio le storie.

Personalmente uso i commenti TODO di tanto in tanto, ma in genere sono di breve durata e di solito ne ho solo un numero molto piccolo come uno, due o tre. Li uso più come marker nella base di codice di ogni altra cosa. Se aspetto troppo a prendermi cura di loro, mi dimentico di quello che pensavo di aver bisogno di "fare".

La mia preferenza sarebbe sempre quella di non usarli e usare invece carte trama o arretrati o simili. Utilizzare un meccanismo per un'attività.

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

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

Per aiutarmi, i nostri build CI sono impostati per 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 essere prioritari come tutti i bug. Penso che questo sia molto meglio che avere alcuni problemi nel DB bug e alcuni nel codice come TODO.

Facoltativamente, puoi quindi inserire un TODO con l'ID bug :-).

Penso che i TODOcommenti, in una certa misura, abbiano un senso. In particolare, se si sta lavorando in modo iterativo (come è comune nei negozi agili e TDD), ci saranno cose che si riconosce sta andando ad essere necessaria in breve tempo, ma che non si desidera effettuare la deviazione per implementare lì e subito.

Ciò che diventa brutto è quando tali commenti rimangono nella base di codice. Mentre stai lavorando attivamente a una funzione, va bene lasciarli dentro, ma non appena ti avvicini al completamento della funzione, dovresti concentrarti sul liberartene. Se non vuoi passare attraverso il lavoro di sostituirli effettivamente con un codice funzionante, allora almeno considera la funzionalità pertinente. Per prendere in prestito l'esempio di @ JoonasPulakka, dove inizialmente dice il codice

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

potresti cambiarlo in qualcosa del genere

ConnManager.getConnection(GetDatabaseName());

con, per il momento, GetDatabaseName () essendo uno stub che restituisce semplicemente la stessa stringa con cui hai iniziato. In questo modo, c'è un chiaro punto di futura espansione e sai che qualsiasi modifica apportata 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, uso una parola chiave tutta mia invece che rigorosamente TODO, sebbene l'intento sia lo stesso: contrassegnare le cose che so dovranno rivisitare. Inoltre, prima di controllare il mio codice, eseguo una ricerca globale del codice sorgente per quella parola chiave, che viene scelta in modo tale che normalmente non dovrebbe apparire in nessuna parte del codice. Se viene trovato, so di aver dimenticato qualcosa e posso andare avanti e risolverlo.

Per quanto riguarda l'inclusione del nome / firma del programmatore nel commento, penso che sia eccessivo se si dispone di un sistema di controllo della versione del codice sorgente ( vero , vero?). In tal caso, la sua funzione di colpa ti dirà chi ha aggiunto il commento o, più precisamente, chi ha verificato l'ultima volta in una modifica che ha toccato il commento. Ad esempio, in Visual Studio, questo è facilmente realizzabile utilizzando la funzione "Annota" presente tra le funzioni di controllo del codice sorgente.

Se scrivi un TODO o FIXME con l'idea che qualcun altro lo risolverà quando arriverà a quel codice in un futuro indeterminato, direi che non ti preoccupare. Spariranno il codice e ingombreranno la parte di segnalazione del tuo IDE che raccoglie queste informazioni.

Per essere utili, dovrebbero fornire un mezzo per aggiungere un segnalibro al tuo codice per il (molto) prossimo futuro in modo da poter tornare più rapidamente nel giusto stato d'animo. In altre parole, li metti nel tuo codice solo per rimuoverli al più presto.

Qualunque cosa più vissuta dovrebbe infatti 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 per l'attenzione mentre è richiesta altrove.

Il mio 2 cent

Di solito non faccio commenti // TODO ma li conservo tutti in file separati. Non riesco ancora a trovare / scrivere software online per gestirli facilmente, quindi i file TODO sono ancora più utili per me perché quando apro il progetto anche dopo poco tempo dimentico cosa fare ora e poi guardo nel file TODO e faccio il lavoro . Ho "nomefile.cpp 354: ricodifica questo bla bla bla" ed è molto più utile quindi cerca il commento // TODO nel file. Ho usato // 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 dal sugo al luogo separato e di tenerli insieme ad altri todos in modo da poter dare priorità ai compiti facilmente. La priorità è TODO davvero difficile quando hai tutti i tuoi TODO in vari file e vari progetti.

Penso che sia fantastico, ma non solo. Per esempio:

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

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

L'enorme vantaggio di fare commenti su uno qualsiasi degli altri milioni di modi in cui uno può creare un elenco di attività è che i commenti 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.

Consiglio vivamente che ogni TODO o FIXME sia inserito in un registro formale. In caso contrario, sono facilmente ricercabili e dovrebbe essere una fase in ogni iterazione per verificare la presenza di 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.

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

In conclusione: sono meglio che non registrare affatto i problemi, ma in realtà devi mantenerli.

IntelliJ ti avviserà effettivamente se provi a eseguire il commit del codice con nuovi TODO. Quindi, puoi sempre interpretare un TODO come "questo dovrebbe davvero accadere quando mi impegno".

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

Negli standard di codifica della mia azienda, specifichiamo che le iniziali dello sviluppatore responsabile devono essere incluse nel TODO ( ovvero , digitare "SAA TODO:"). Penso che questo sia utile, almeno come una convenzione, perché altrimenti c'è la tentazione di lasciare un codice scadente con la nota TODO per far fronte ad alcuni sviluppatori futuri.

Utilmente, molti IDE possono essere configurati per aggiungere questi commenti a un elenco di attività, consentendo loro di essere trattati in modo simile per creare errori e non dimenticati indefinitamente.

Un metodo più odioso ma efficace è probabilmente quello di trasformare i tuoi commenti todo in messaggi di compilatore, in questo modo tu e tutti gli altri lo vedete quando il programma viene compilato.

a Delfi:

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

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

TODOle annotazioni non dovrebbero essere utilizzate per indicare che alcune parti di codice sarebbero più belle se modificate in qualche modo. Gli esempi includono il codice sporco che sarebbe più gestibile se riscritto o una funzionalità extra che nessuno ha ancora bisogno. Quelle annotazioni tendono ad accumularsi e grep TODOrestituiscono risultati inutili.