Vecchio codice nei commenti [chiuso]

Question

Per quanto tempo dovresti tenere il vecchio codice commentato nella tua base di codice? Gli appaltatori continuano a conservare il vecchio codice nella base di codice trasformandolo in commenti. Questo è davvero frustrante e voglio che rimuovano semplicemente il vecchio codice invece di commentarlo.

Esiste un motivo valido per mantenere il vecchio codice nella base di codice come commenti? Sto usando il controllo versione da Visual Sourcesafe

Answer 1

Se usi qualcosa come SVN o CVS, no. Li cancellerei a vista. Rendono il codice meno leggibile.

I commenti dovrebbero essere lì per aiutare il programmatore che sta leggendo il codice, spiega cose, ecc.

Answer 2

Un motivo valido che mi viene in mente è questo esempio (immaginario):

# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a

Fondamentalmente, per impedire ad altri sviluppatori di reinserire il codice che è stato rimosso per un motivo.

Answer 3

Di 'ai contraenti di smettere di farlo. Questa è una pratica terribile.

Non c'è davvero alcun motivo per mantenere il vecchio codice nella base di codice; si mette solo in mezzo. Il tuo sistema di controllo della versione ti mostrerà la cronologia di ciascun file.

L'unica ragione forse valida per mantenere il vecchio codice è forse possibile per riferimento storico (forse se il vecchio codice ha fatto qualcosa di particolarmente strano che potrebbe essere rilevante per la situazione attuale).

Occasionalmente commenterò semplicemente il codice sapendo che sto inserendo una modifica temporanea (per temporaneo intendo meno di qualche giorno) e sicuramente pianificherò di tornarci.

modifica: un'altra pratica correlata sta inserendo nomi e date delle modifiche nel file:

// 06/20/2009 - joe changed this #1245

Non farlo neanche. Potrebbe sembrare prezioso al momento vedere chi ha apportato una modifica, ma col tempo non ha davvero alcun valore e ingombra il codice.

Answer 4

Se stai usando il controllo del codice sorgente che dovresti essere, rimuovi il vecchio codice poiché una copia sarà pronta per il controllo del codice sorgente e ti aspetterà se dovessi mai aggiungerlo di nuovo. Avere il vecchio codice lì dentro ridurrà la capacità di leggere il codice come indicato sopra e introdurre confusione. Inoltre, se stai utilizzando appaltatori per scrivere il tuo codice, digli come codificare mentre stai pagando il loro stipendio. Definire gli standard di codifica per loro e farli codificare intenzionalmente che dovrebbe migliorare il nome di metodi, proprietà ecc. E ridurre la necessità di commenti tutti insieme.

Answer 5

Chiedi a " quanto tempo? " Non sono offeso dall'avere il vecchio codice in uno o due posti se quelli sono i punti caldi in cui le persone lavorano ancora.

Forse non si sentono ancora sicuri del nuovo codice. Il nuovo codice " fatto? & Quot; È scritto come dovrebbe essere? Supera i test? È commentato e documentato in base alle specifiche? La performance è dove dovrebbe essere? (Il miglior motivo per cui riesco a pensare di avere sia il vecchio che il nuovo codice è quando sto programmando o profilando un certo numero di casi.)

C'è qualcosa nel vecchio codice che è preferibile al nuovo codice?

Gli appaltatori si sentono di fretta? O è solo una vecchia abitudine dei giorni di controllo pre-versione?

Answer 6

Quando ricordi agli appaltatori che non devono commentare il codice poiché Sourcesafe manterrà la cronologia chiedendo loro perché lo stanno facendo.

Potrebbe essere che non si fidino per qualche motivo. Se riesci a tirar fuori quella ragione, potrebbero prestare attenzione. So che quando ci siamo trasferiti da VSS molti anni fa è stato a causa di problemi di affidabilità e scalabilità a cui potrebbero essere stati esposti. Se puoi rispondere alle loro preoccupazioni, dimostrando che VSS è adeguato alle tue esigenze o dicendo che indagherai su altre soluzioni di controllo del codice sorgente (se hai il budget, ovviamente), dovresti conquistarle.

La persuasione è meglio della coercizione.

Answer 7

Sì, ammazzalo a vista. Non dà altro valore che dimostrare che lo sviluppatore che lo ha commentato non era sicuro della sua rimozione. Oppure non sanno come utilizzare il tuo software di controllo del codice sorgente.

Answer 8

Fondamentalmente, hai solo 2 opzioni.

1. Rimuoverlo: questo è quando si utilizza un repository di codice. Il tuo repository ti dirà esattamente quali modifiche sono state apportate, quindi non è necessario conservare lunghi commenti nel tuo codice di lavoro, che non spiega qualcosa in un linguaggio semplice.
2. D'altra parte, se si desidera conservare quel codice per diversi motivi, ad esempio, ho tenuto commentato un codice di calcolo in virgola mobile nella mia applicazione, poiché non funzionava sulla piattaforma, per cui stavo programmando. Ma poiché non vorrei che la mia applicazione rimanesse limitata a quella piattaforma, ho mantenuto il codice lì, in modo da risparmiare lo sforzo quando porto l'applicazione su una piattaforma che supportava i calcoli in virgola mobile. Questo è solo uno dei motivi per mantenere il vecchio codice e potrebbe essere applicabile a persone dello stesso background.

Altrimenti, sopra menzionate sono le uniche 2 scelte. La tua chiamata !!

Answer 9

Mantenere il vecchio codice in giro rende solo più difficile leggere il codice nel suo insieme. Finché esiste una forma di controllo della versione per il progetto, il codice commentato deve essere eliminato. Se non si dispone del controllo di revisione e non è possibile configurarlo, è consigliabile posizionare il vecchio codice in un file che non fa parte della base di codice.

Answer 10

Suppongo che ti riferisca a blocchi di codice significativi che sembrano avere un certo valore, o buoni algoritmi a sé stanti, non solo la linea dispari qui o là.

In questi casi, c'è una naturale tendenza a conservare il codice, se hai apportato grandi modifiche mantenendo il vecchio mentre i commenti agiscono come una forma di revisione del codice. Chiunque ottenga la versione più recente sarà in grado di vedere immediatamente le grandi modifiche apportate e, se si verifica un problema, è molto più facile vedere ciò che era lì. Se il problema riguarda il nuovo codice, esiste un modo molto semplice per verificarlo immediatamente.

Quindi, dato ciò, tendo a commentare il vecchio codice per la prima revisione, e quindi a eliminarlo solo quando il codice viene successivamente modificato di nuovo, a questo punto il cambiamento sarà stato 'inserito' e probabilmente non lo sarà una causa di bug.

Questi commenti sono una forma di documentazione, non è necessario rimuoverli per qualsiasi ideale purista di codifica "pulita". Rimuovili quando non sono più necessari, tienili mentre possono essere utili.

Answer 11

Per prima cosa, dico di liberarmene.

Ma conosco un motivo per non farlo: mentre è ancora presente nel controllo della versione, ciò non significa che nessuno possa vederlo. Se potresti aver bisogno di vederlo di nuovo, devi prima sapere che esisteva una volta. A volte fai una modifica che i futuri sviluppatori hanno bisogno di vedere sia il vecchio che il nuovo modo e se rimuovi il vecchio modo, come fanno gli sviluppatori a sapere che c'era una volta lì? La maggior parte delle persone non documenta abbastanza bene i cambiamenti nel controllo della versione per questo tipo di problema.

Answer 12

Tanti motivi per lasciare lì il vecchio codice. Fondamentalmente - una volta che è stato eliminato, è effettivamente sparito - a meno che qualcuno non si ricordi effettivamente che era lì.

In qualità di contraente malvagio, non elimino il codice a meno che non stia facendo una sostanziale riscrittura di una procedura, eliminandola e sostituendola piuttosto che "riparando". esso.

Answer 13

Il progetto che sto attualmente presentando, utilizza ancora un altro approccio: una sorta di compromesso ... Quando decidi che una parte del codice non deve più essere utilizzata, devi semplicemente commentarla, scrivere una data di commentando e (se possibile - ad esempio in Netbeans o VisualStudio) si inserisce il vecchio codice in #region OLD_IMPL. Effetto? - Hai ancora un vecchio codice per ogni evenienza - Il blocco di codice inutilizzato richiede esattamente 1 riga (#region OLD_IMPL) - Se vedi, quel codice non viene utilizzato per un anno (hai la data di commentarlo), puoi semplicemente cancellarlo.

In caso di situazioni critiche usi sempre SVN;)

Answer 14

Coloro che dicono di sbarazzarsi del codice commentato perché gli strumenti di controllo della versione risolveranno qualsiasi problema in cui potresti imbatterti, sono idioti.

Devi liberarti del codice obsoleto, UNA VOLTA CHE SEI POSSIBILMENTE SICURO CHE È VERAMENTE OSSOLETE.

Mai dovuto rivedere una modifica perché " non era del tutto negativo, ma purtroppo non era nemmeno del tutto & " ? Se puoi ancora estrarre la fonte di produzione e SAPERE che la versione precedente del codice è ancora lì, in una forma testuale, ti farà risparmiare un sacco di tempo, perché non dovrai ricorrere a complessi, difficili da -controllare e quindi processi molto inclini all'errore di usare qualsiasi "fusione di fonte parziale" e "consolidamento parziale della fonte" che il tuo strumento di controllo della versione può offrirti.

Le persone a cui questa realtà non piace sicuramente devono aver trascorso tutta la loro carriera producendo solo codice che non è mai stato "non del tutto negativo, ma non del tutto buono", o in altre parole, producendo solo codice che era del tutto cattivo oppure del tutto perfetto. E sappiamo tutti quanto è grande la probabilità di raggiungere quest'ultimo.