Esiste un metodo per differenziare i commenti informativi dal codice commentato?

Durante tutto il corso della programmazione, finirai con alcuni commenti che spiegano il codice e alcuni commenti che rimuovono il codice:

// A concise description 
const a = Boolean(obj);
//b = false;

Esiste un buon metodo per analizzare rapidamente quale è quale?

Ho giocato con l'uso di 3 /e /** */per commenti descrittivi.

Ho anche usato un plug-in VSCode per evidenziare //TODO:e//FIXME:

Esiste una soluzione molto semplice: rimuovere il codice commentato.

In realtà, ci sono solo due buoni motivi per commentare il codice: per testare qualcosa / fare una correzione, o per salvare il codice che potresti usare in seguito. Se stai testando o risolvendo qualcosa, rimuovi il codice commentato non appena hai finito con il test o la correzione. Se stai salvando il codice che potresti utilizzare in un secondo momento, rendilo un codice di prima classe e mettilo da qualche parte come una libreria in cui può essere utilizzato.

Aggiungendo alla risposta eccellente di @ RobertHarvey credo che ci sia solo una ragione legittima che abbia mai incontrato per salvare il codice commentato sul controllo del codice sorgente, anche temporaneamente: in caso di codice di sostituzione non ovvio che non dovrebbe o non può essere usato in questo momento per qualche motivo . Anche allora la maggior parte del commento dovrebbe essere la spiegazione, non il codice di sostituzione. Potrebbe trattarsi di un bug o di una caratteristica del linguaggio che non è ancora considerata stabile. Potrebbe assomigliare a questo:

# TODO: Replace with `foo = frobnicate(bar)` once <link.to/bug> is fixed
foo = [some complex workaround]

In questo caso, il lavoro è già stato fatto, ma non puoi ancora sfruttarlo, quindi eliminarlo significa che qualcuno dovrebbe riscoprirlo in un secondo momento. Lo stesso vale per soluzioni non ottimali che possono sembrare superiori o compromessi consapevoli rispetto a soluzioni simili .

Attenzione: non sporcare il codice con soluzioni alternative. Ogni attività può essere eseguita in infiniti modi diversi e non è conveniente esplorare questo spazio a lungo per ogni cambiamento. Le revisioni del codice possono essere un buon posto per scoprire tali commenti mancanti, quando il collega suggerisce un miglioramento che hai già scoperto essere non ottimale.

Hmm, ho letto questa domanda in modo leggermente diverso da Robert che afferma correttamente che il codice commentato dovrebbe essere rimosso.

Se, tuttavia, stai cercando una convenzione per contrassegnare il codice per la successiva rimozione, un mio vecchio preferito è:

//b = false; //TODO: remove

Alcuni //TODO:commenti della bandiera di IDE o possono essere insegnati a. In caso contrario, di solito è una stringa ricercabile. È meglio seguire qualsiasi convenzione stabilita dal tuo negozio perché ciò può essere fatto in diversi modi. Ogni base di codice dovrebbe farlo in un modo. Mantiene la ricerca.

analizzare rapidamente quale è quale?

Senza quel segno, il modo automatico per farlo è con il compilatore. Se la rimozione del commento produce codice che viene compilato, deve essere stato un codice commentato. Scrivere un plugin IDE che controlla che non sarebbe difficile. Ma lascerà dietro di sé il codice commentato con errori.

Ecco perché è meglio contrassegnare semplicemente il codice commentato come codice nel momento in cui lo commentate. Questo ti consente di lavorare in modo non distruttivo mentre decidi se lo vuoi davvero andare. Dato che tutti siamo interrotti e siamo in qualche modo smemorati, non stupitevi se alcune linee vengono registrate mentre si trovano in quello stato. Se lo fanno è bello che siano almeno chiaramente contrassegnati e ricercabili. Le macro della tastiera mi hanno aiutato con questo in passato. È difficile essere interrotti nel mezzo di questo se riesci a farlo con un solo tasto.

Puoi prenderlo fino a sancire il segno nei tuoi test di integrazione continua. Oops, sto provando a fare di nuovo il check-in con TODO eccezionali.

Uso le direttive del preprocessore per rimuovere il codice, non i commenti:

//comment
active_code();
#if FALSE
inactive_code();
#endif

Questo rende molto facile la ricerca e il mio evidenziatore di sintassi lo considera come un commento. Posso persino comprimerlo in una sola riga:#if FALSE(...)

Puoi espandere l'idea per avere diverse opzioni:

#if OPTION == 0
code_for_option_0();
#elif OPTION == 1
code_for_option_1();
#else
code_for_all_other_options();
#endif

E controllo errori in fase di compilazione:

#if FOO >= 5
#error FOO should be less than 5!
#endif

Naturalmente, non vuoi esagerare con questo, o diventa difficile dire cosa viene effettivamente compilato e cosa no. Ma hai l'idea, ed è lo stesso problema del codice commentato ... purché lo usi solo staticamente. Se le tue condizioni sono dinamiche, è peggio.

Per determinare quale sia quale in una base di codice esistente che non ha considerato affatto questo problema, non penso che ci sia una soluzione universale. Dovrai trovare tu stesso i pattern e probabilmente codificare una regex per trovarli.

Concordo con la risposta affermando che il vecchio codice dovrebbe essere rimosso piuttosto che commentato ove possibile, tuttavia ho osservato una convenzione per quelle poche occasioni in cui è necessario un codice commentato.

(La mia base è C # ma questo può essere applicato a qualsiasi linguaggio di sintassi C, ad esempio java)

// An explanatory comment has a space between the comment marker and the content.

// The following lines are commented out code so do not have the space (except where indented).
//var a = something();
//if(a==2) {
//   doSomethingElse();
//}

Sto ancora interpretando la domanda in modo diverso, pensando che tu voglia trovare un codice commentato.

Il codice in stile C deve contenere punti e virgola, mentre è improbabile che nel commento siano presenti punti e virgola. Quindi per il codice commentato a riga singola è possibile utilizzare questa espressione regolare:

\s*\/\/[\s\S]*;

Per il codice commentato su più righe potrebbe essere

\/\*[^\;]*;[^\;]*\*\/

Nota Visual Studio è un po 'peculiare delle interruzioni di riga nelle espressioni regolari, non contano come spazi bianchi, è necessario specificare un esplicito \ n.

Se usi un editor con un compilatore in esecuzione in background (come Xcode e Clang), puoi semplicemente provare a compilare il testo del commento. Ad esempio "una descrizione concisa" fornisce errori, "b = false;" no. È quindi possibile utilizzare l'evidenziazione della sintassi diversa.

Un metodo più semplice sarebbe un plug-in IDE che utilizza alcune euristiche, come più parole di fila diverse dalle parole chiave puntano a commenti, abbinano il punto tra parentesi graffe al codice ecc.

Altre risposte hanno coperto variazioni sul tema "Non commentare il codice". Ma a volte lo vuoi ancora in giro per riferimento.

Se hai davvero bisogno del codice per rimanere in giro, una soluzione migliore è circondare il codice con "#if 0 ... #endif", idealmente con un commento per dire il perché. Questa è la strategia raccomandata da vari standard di codifica, incluso MISRA.

Semplice, almeno per me - e in C / C ++. I commenti racchiusi in / * * / sono informativi. Il codice di prova che viene temporaneamente rimosso viene commentato con il comando //.

E c'è una buona ragione per lasciare il codice di prova nel file ma commentato, almeno nel tipo di lavoro che faccio. Prima o poi qualcuno vorrà apportare una modifica, che avrà bisogno di quel codice. Uncommenting un blocco richiede un comando dell'editor, così come commentare nuovamente dove hai finito.