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?

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

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

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

Alla fine della giornata, fai le cose nel modo migliore per te. Anche se si trattasse di un progetto di squadra, se rimuovi tutto il codice commentato non peschi nessuno.

May I ask what are these downsides of what I'm doing that I'm failing to see now?

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

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

Se usi il controllo di versione e hai un carico di commenti come "elenco di cose da fare", e ne aggiusti alcuni e rimuovi il commento, quindi ripeti, poi ripeti ecc ... allora hai il codice "work in progress" e commenti salvati nella cronologia delle revisioni. Questo non sarà un problema se non hai mai bisogno di tornare a un altro commit o anche "cherry pick" più tardi (questo è ad esempio dove si prendono specifici commit e li si trascina in un altro ramo da utilizzare). Ma altrimenti potrebbe essere un problema.

Probabilmente questo può essere paragonato a "snap shot" del software del disco rigido, come Windows (la cosa di Ripristino). Se ci vuole un'istantanea con un virus al suo interno, uccidi il virus, ma in seguito devi eseguire il rollback, puoi tornare al punto in cui il virus è nuovamente presente.

Questo approccio è anche probabile come un problema quando usi il controllo di versione e lavori con altri sviluppatori, dato che devono vedere tuo Elenco di cose da non usare per loro. In realtà, è 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 documentazione per "come funziona" e software per tenere traccia di ciò che deve essere fatto (ovvero todo).

Inoltre, quando lavori su un progetto più ampio tendi a collaborare, a impegnarti e a spingerlo spesso, quindi è possibile che il loro ramo su cui stanno lavorando abbia la tua lista TODO se uniscono 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 di versione, ingombra la cronologia e può essere confuso con altri sviluppatori.

E, questa è una cosa personale per certi aspetti, ma usare una base di codice come "elenco delle cose da fare" non è l'ideale. Un giorno potresti lasciare qualcosa per sbaglio o dimenticarti di commentarlo o di non commentarlo per errore.

Come con molti approcci all'architettura, alla codifica e a come lavori personalmente o il tuo team, ogni scenario può richiedere qualcosa di diverso. Quindi considera gli svantaggi menzionati e i vantaggi dell'uso del controllo di versione e decidi se funziona per tu .

Sembra che il tuo revisore sia un po 'dogmatico. Non sono sicuro che giurare a qualcuno per aver commentato il codice è PC ;-), o anche utile; -)

Ma più seriamente, penso che il tuo revisore abbia ragione, che dovresti prendere seriamente in considerazione l'idea di usare git (o qualche altro sistema di controllo del codice sorgente, ma git è una scelta sensata).

E così facendo potresti alleviare alcune delle tue necessità di commentare il codice.

Ma avere una lista TODO all'interno del codice (se elenchi puntati o vecchio codice) - è abbastanza ragionevole a mio parere. Ma potresti voler riconsiderare un po 'come lo fai. Per prima cosa, ti suggerisco di pensare a qualcun altro che legge il tuo codice. Che qualcun altro potrebbe essere te, un anno dopo che sei rientrato e ricongiungerti a un progetto. O potrebbe essere qualcun altro interamente. SOLO incontrare codice commentato è un po 'confuso. Forse qualcosa come:

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

Personalmente, mi chiamo di più verso qualcosa di simile:

 * 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 '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 un team e comunicare con un team, e git è esattamente come è fatto oggigiorno. E una volta che hai finito di usarlo, troverai il suo strumento / stampella MOLTO utile, rendendo più facile lo sviluppo del tuo software.

Buona fortuna!

Ci sono molti motivi per commentare il codice: -

• Non è ancora corretto, e lo annulli quando è pronto.
• Stai commentando temporaneamente per modificare il comportamento durante il debug.
• Non sei sicuro che il codice sia necessario, ma non vuoi eliminarlo finché non ne hai ancora testati.
• Il codice è necessario per alcune versioni del software, ma non per questo.
• Il codice è obsoleto, ma ci sono voluti anni per scrivere e tu sei emotivamente attaccato ad esso. Inoltre, potrebbe essere utile un giorno.

Il problema si presenta quando metti a letto il codice, poi ti ritorni un paio di anni dopo per fare manutenzione. Troverete il codebase pieno di codice commentato. Non sarà più chiaro il motivo per cui nessuno di essi è lì, ed ora è solo confusione.

Se si utilizza uno strumento di controllo della versione semi-decente, è possibile cancellare in grassetto qualsiasi codice che non è più necessario, con la certezza che il sistema di controllo della versione lo conserva ancora. Un file diff tra le versioni rivelerà ciò che è stato cancellato. Una volta implementato il controllo della versione, l'unica necessità di commentare è per cose temporanee. Se trovi mai un codice commentato in file su cui non stai lavorando, puoi semplicemente cancellarlo.

Non ripeterò il motivo per cui dovresti usare il controllo del codice sorgente anche per i progetti di una sola persona, poiché ci sono molte altre risorse là fuori che ti diranno di farlo. Ma uno dei principali aspetti negativi del tuo attuale approccio è che se commenti un codice, lo nascondi dal tuo IDE (se non stai utilizzando un IDE dovresti probabilmente prenderlo in considerazione).

Ad esempio, se vuoi rinominare un metodo o una classe, o cambiare il numero di parametri che un metodo richiede, l'IDE dovrebbe avere un'opzione refactor per fare ciò che troverà tutti i riferimenti appropriati e aggiornarli di conseguenza - ma probabilmente non cercherà nei commenti.

Invece di cercare di indovinare dove è necessario apportare modifiche, è sufficiente crearle e lasciare che il tuo IDE ti indichi dove le modifiche hanno causato la rottura delle cose. Puoi quindi commentare il codice in modo più chirurgico e, si spera, per un periodo di tempo più breve prima di correggere qualsiasi cosa si sia rotta.

È cattivo e dovresti fermarsi .

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

Se commentate ampie sezioni di codice, correggete un po 'e registrate, quindi avete controllato il codice non funzionale. e un intero carico di materiale commentato che altri supporteranno è vecchio e può essere ignorato

Se non effettui il check-in spesso, accumuli conflitti di fusione e non registri i progressi passo dopo passo.

Devi cambiare il tuo modo di lavorare in modo che se devi fermarti a metà strada tutto funziona ancora.

Fai piccoli passi e fai il check-in dopo ogni:

• estrai un'interfaccia
• scrivi un test
• refactifica una funzione

Non contrassegnare grossi pezzi di codice come "tuoi" commentandoli e portali via per lavorare da soli fino a quando non sono completi o fallisci.

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