Perché è sbagliato commentare il codice e poi rimuoverlo gradualmente per tenere traccia di ciò che ho già fatto e di ciò che resta da fare?

Ogni volta che scopro che una grande parte del mio codice deve essere modificata, sia perché non è corretta o perché deve essere adattata alle principali modifiche architettoniche richieste da altri motivi, questo è ciò che faccio in genere:

1. Commento tutto il codice che sospetto possa essere necessario modificare. Considero il codice commentato come una specie del mio elenco TODO.
2. Riesco a rivedere gradualmente il codice commentato e le parti di decommenting di questo codice, o copiarlo e incollarlo altrove, quindi modificarlo come necessario, o riscrivere parti di questo codice da zero, guardando il codice commentato per riferimento. Ogni volta che penso di aver finito con una parte del codice commentato, lo rimuovo.
3. Continuo fino a quando non vedo più il codice commentato.

Dovrei notare che lo sto facendo in gran parte sul progetto personale che sto sviluppando da solo.

Tuttavia, mi è stato detto che avrei dovuto smettere di farlo. Mi è stato detto che invece, dovrei iniziare a usare git, facendo riferimento ai vecchi commit per vedere il vecchio codice, invece di lasciare il codice commentato. Mi fu detto:

Commentare il codice è una cattiva abitudine che dovrebbe essere spazzata via. Ti manca l'esperienza, quindi non riesci a capirlo. Se, tra qualche anno, vedi il codice di un'altra persona a cui piace commentare il codice, inizierai a imprecare contro questa persona. Ogni volta che vedo codice commentato, lo rimuovo nella sua interezza, senza nemmeno guardarlo, perché di solito tale codice è completamente senza valore. Certamente non vedrai gli svantaggi del commentare il codice in piccoli progetti individuali; ma se trovi un lavoro e tieni questa abitudine, sarà un peccato.

Posso chiedere quali sono questi aspetti negativi di quello che sto facendo che non riesco a vedere ora?

Devo dire che non mi interessa davvero usare solo git per vedere il codice passato. Come ho detto, considero commentare il codice come una sorta di todo-list; mentre git mi mostrerà come appariva il codice, non mi mostrerà chiaramente quali parti del codice sono ancora necessarie per essere riviste e quali sono già state fatte. Temo che potrei perdere qualche parte del codice e introdurre bug.

Per completezza, sento che dovrei aggiungere che la persona che sto citando è uno sviluppatore esperto e un fan del "Clean Code" di zio Bob - e lo zio Bob ha criticato duramente il suo codice nel commentare il suo libro.

Se alla fine rimuovi tutto il codice commentato, non vedo alcun problema reale con questo. Lasciare il codice commentato nella tua base di codice è una cattiva pratica, ma non è quello che stai facendo se riesci ad eliminarlo. Sospetto che la persona con cui stai parlando o non capisca il processo che stai utilizzando o sia dogmatica.

In realtà, il codice commentato è innocuo. Il problema è che è disordinato e rende difficile la lettura. Ci sono peccati molto peggiori ma è una cosa molto semplice da eliminare. Come persona che ha commentato il codice, sei nella posizione migliore per determinare che può essere rimosso completamente.

Molti IDE e editor di codice comprendono una sorta di sintassi "TODO" nei commenti. Questo è un modo alternativo per contrassegnare ciò che deve essere cambiato. Potresti considerare questo dato che fornisce un po 'più di informazioni su cosa stavi pensando quando lo hai contrassegnato.

Alla fine della giornata, fai le cose nel modo che ti darà il miglior risultato. Anche se si trattasse di un progetto di gruppo, purché rimuova tutto il codice commentato non stai caricando nessun altro.

Posso chiedere quali sono questi aspetti negativi di quello che sto facendo che non riesco a vedere ora?

Probabilmente, nessuno se lavori da solo e non usi il controllo versione e ritieni che sia giusto farlo in questo modo.

In effetti, senza il controllo della versione, non importa molto quello che fai in qualsiasi momento in "time" poiché il codice è sempre qualunque sia lo stato in cui il file corrente viene "salvato" come nel sistema operativo.

Se usi il controllo versione e hai un sacco di commenti come "todo list", e ne aggiusti alcuni e rimuovi il commento, quindi ripeti, quindi ripeti ecc ... hai quindi il codice "work in progress" e i commenti salvati nella cronologia delle revisioni. Questo non sarà un problema se non dovessi mai tornare indietro a un altro commit o anche "cherry pick" in un secondo momento (questo ad esempio è dove prendi specifici commit e li trascini in un altro ramo per essere utilizzato). Ma per il resto potrebbe essere un problema.

Probabilmente questo può essere paragonato alle "istantanee" del software del disco rigido, come aveva fatto Windows (la cosa del Restore). Se si esegue un'istantanea con un virus, si uccide il virus, ma in seguito è necessario eseguire il rollback, è possibile tornare a un punto in cui il virus è nuovamente presente.

È probabile che questo approccio rappresenti un problema anche quando si utilizza il controllo versione e si lavora con altri sviluppatori, poiché devono quindi vedere l' elenco delle cose da fare che non ha alcuna utilità. In effetti, è solo un disordine che devono ignorare e aggirare. Nei nostri team rimuoviamo sempre tutti i commenti, come il vecchio codice o le "note". A meno che non siano utili, tuttavia questo è molto raro perché abbiamo una documentazione per "come funziona" e un software per tenere traccia di ciò che deve essere fatto (aka todo).

Inoltre, quando lavori su un progetto più ampio, tendi a collaborare, a impegnarti e a spingere spesso, quindi è possibile che il loro ramo su cui stanno lavorando abbia il tuo elenco TODO se hanno unito il tuo ramo al loro. Quindi la tua lista TODO è affare di tutti: D

In sintesi, se non lavori da solo e specialmente quando usi il controllo versione, ingombra la cronologia e può essere ingombrante per altri sviluppatori.

E questa è una cosa personale per alcuni aspetti, ma usare una base di codice come "todo list" non è l'ideale in realtà. Un giorno potresti lasciare qualcosa per sbaglio, o dimenticare di commentarlo o di decommentarlo per errore.

Come con molti approcci all'architettura, alla programmazione e al modo in cui tu o il tuo team lavorate, ogni scenario può richiedere qualcosa di diverso. Quindi considera gli svantaggi menzionati e i vantaggi dell'utilizzo del controllo versione e decidi se funziona per te .

Sembra che il tuo recensore sia un po 'dogmatico. Non sono sicuro che imprecare a qualcuno per commentare il codice sia PC ;-) o addirittura utile ;-)

Ma più seriamente, penso che il tuo recensore abbia ragione, che dovresti seriamente considerare di usare git (o qualche altro sistema di controllo del codice sorgente, ma git è una scelta sensata).

E ciò potrebbe alleviare alcune delle tue necessità di commentare il codice.

Ma avere un elenco TODO all'interno del codice (sia elenchi puntati o vecchio codice) - secondo me è abbastanza ragionevole. Ma potresti voler riconsiderare un po 'come lo fai. Per prima cosa, suggerisco di pensare a qualcun altro che legge il tuo codice. Che qualcun altro potresti essere tu, un anno dopo essere caduto e ricongiungerti a un progetto. O potrebbe essere qualcun altro del tutto. SOLO incontrare codice commentato è un po 'confuso. Forse qualcosa del tipo:

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

Personalmente, mi rivolgo più a qualcosa del genere:

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

e mi sento libero di inserire "frammenti di codice" dal vecchio codice come utili.

Usare git è difficile (purtroppo). Ci vorrà un po 'di tempo per imparare e potrebbe sembrare che non faccia parte di ciò che stai cercando di realizzare. Ma se hai intenzione di programmare in modo utile, dovrai imparare a farlo come parte di una squadra e comunicare con una squadra, e git è proprio come viene fatto al giorno d'oggi. E una volta che hai iniziato a usarlo, troverai uno strumento / stampella MOLTO utile, che semplifica lo sviluppo del tuo software.

Buona fortuna!

Esistono molti motivi per commentare il codice: -

• Non è ancora giusto e non lo commenterai quando sarà pronto.
• Lo stai commentando temporaneamente per modificare il comportamento durante il debug.
• Non sei sicuro che il codice sia necessario, ma non vuoi eliminarlo fino a quando non avrai provato di più.
• Il codice è necessario per alcune versioni del software, ma non per questo.
• Il codice è obsoleto, ma ci sono voluti anni per scrivere e sei emotivamente attaccato ad esso. Inoltre, potrebbe essere utile un giorno.

Il problema si presenta quando metti il ​​codice a letto, poi ci ritorni un paio di anni dopo per fare un po 'di manutenzione. Troverai la base di codice piena di codice commentato. Non sarà più chiaro il motivo per cui c'è qualcosa, e ora è solo un disordine.

Se si utilizza uno strumento di controllo della versione decente, è possibile eliminare con audacia qualsiasi codice non più necessario, al sicuro sapendo che il sistema di controllo della versione lo ha ancora archiviato. Un file diff tra le versioni rivelerà ciò che è stato eliminato. Una volta implementato il controllo della versione, l'unica necessità di commentare è per cose temporanee. Se trovi codice commentato nei file su cui non stai effettivamente lavorando, puoi semplicemente cancellarlo.

Non ripeterò perché dovresti usare il controllo del codice sorgente anche per i progetti di una persona, poiché ci sono molte altre risorse là fuori che ti diranno di farlo. Ma uno dei principali svantaggi del vostro attuale approccio è che se commentate il codice, lo nascondete al vostro IDE (se non state usando un IDE dovreste probabilmente considerarlo).

Ad esempio, se desideri rinominare un metodo o una classe o modificare il numero di parametri che un metodo accetta, il tuo IDE dovrebbe avere un'opzione refactor per fare ciò che troverà tutti i riferimenti appropriati e li aggiornerà di conseguenza, ma probabilmente vincerà " t cerca nei commenti.

Invece di provare a indovinare dove è necessario apportare modifiche, basta apportarle e lasciare che il tuo IDE ti dica dove le modifiche hanno causato le cose. È quindi possibile commentare il codice in modo più chirurgico e, si spera, per un periodo di tempo più breve prima di risolvere qualsiasi problema.

È male e dovresti smettere .

Il motivo si riduce al tentativo di eseguire una grande quantità di refactoring in una volta sola.

Se aggiungi commenti a grandi sezioni di codice, correggi un po 'e fai il check-in, allora hai verificato il codice non funzionale. e un sacco di cose commentate che gli altri presumono siano vecchie e che possano essere ignorate

Se non effettui il check-in spesso, stai accumulando conflitti di unione e non stai registrando i progressi passo dopo passo.

Devi cambiare la tua pratica di lavoro in modo che se devi fermarti a metà strada tutto funziona ancora.

Fai piccoli passi e fai il check-in dopo ciascuno

• estrarre un'interfaccia
• scrivi un test
• refactor una funzione

Non contrassegnare grossi blocchi di codice come 'tuoi' commentandoli e portali via per lavorarci da soli fino a quando non sono completi o non ci riesci.

Se devi tenere traccia di ciò che deve essere fatto, usa una task board come scrum o trello