Devo rimuovere il codice non referenziato?

La maggior parte delle ragioni per mantenerlo sono del tutto irrilevanti, in parole povere. Se il codice non viene utilizzato, gettalo via - qualsiasi vantaggio implicato nel mantenerlo può essere banalmente derivato dal controllo del codice sorgente. Al massimo, lascia un commento indicando in quale revisione trovarlo.

Molto semplicemente, prima si taglia il codice, prima non si deve perdere tempo a mantenerlo, compilarlo e testarlo. Questi vantaggi superano di gran lunga i benefici insignificanti che hai delineato, comunque tutti derivati dal controllo del codice sorgente.

Tutti i motivi per rimuoverlo.

Motivi per tenerlo:

• Può essere usato come riferimento
• Potrebbe essere utile qualche volta
• Potrebbe essere stato scritto per "arrotondare" la funzionalità di una classe

Tutti questi motivi per mantenerlo saranno gestiti dal controllo del codice sorgente. Rimuovilo dal codice live e sarai in grado di recuperarlo se / quando è necessario.

Il codice non referenziato è lo stesso di tenere quelle batterie che sono un po 'piatte, tipo piatto nel caso in cui ne hai bisogno un giorno per una torcia.

Finché utilizzi una sorta di controllo di versione, direi di eliminarlo dal codice live e utilizzare la cronologia delle versioni nel caso in cui risulti utile.

L'unica buona ragione che posso vedere per mantenere il codice che non è attualmente utilizzato è se fa parte di un modulo autonomo: mentre alcune parti del codice potrebbero non essere utilizzate al momento, potrebbe essere che saranno utilizzati in futuro.

Questo potrebbe essere particolarmente vero per una libreria che si utilizza in diversi progetti: non si vuole continuare a lanciare pezzi di codice dentro e fuori, in base a ciò che è necessario per un progetto specifico: Trovo che questa operazione richieda tempo ed errori prona.

Il mio approccio è: (1) se lo usi una volta, mantieni solo ciò di cui hai veramente bisogno; (2) se lo usi due volte, copialo e adattalo la seconda volta che lo usi; (3) se lo usi più di due volte, crea un modulo ben definito e stabile e usa questo modulo di cui hai bisogno.

Riassunto: butterei via tutto il codice inutilizzato a meno che non faccia parte di un modulo generico che tu abbia progettato come tale e che tu sappia che dovrai riutilizzare più volte.

Nota : naturalmente, una soluzione ancora più pulita sarebbe quella di creare un progetto separato per una libreria e aggiungere una dipendenza tra i progetti.

In generale, mi inchinerei a YAGNI su questo. Se "non ne avrai bisogno", significa semplicemente occupare spazio nella base di codice, nelle unit test e negli assembly. Potresti finire per averne bisogno, ma potresti anche doverlo riscrivere completamente perché tra ora e quando hai bisogno di qualcosa di simile, molto può cambiare.

Tuttavia, questo cambia leggermente quando si scrive un'utilità o un'API destinata al consumo generale. Proprio come non puoi mai aspettarti che gli utenti finali del software interagiscano con il software nel modo che intendevi, non puoi mai aspettarti che i consumatori del tuo codice vogliano utilizzare il tuo codice esattamente nel modo in cui pensi che dovrebbero. In questi casi, purché tu possa giustificare l'esistenza di un metodo con "è un modo valido per voler interagire con il mio oggetto", allora probabilmente dovrebbe entrare, perché anche se non ne avrai bisogno, è probabile che QUALCUNO possa .

Dato che il codebase ha meno di un anno, probabilmente è ancora in flusso (sì?) - quindi la nozione che alcuni bit potrebbero dover essere resuscitati nel prossimo futuro non è irragionevole.

Per i bit che all'inizio erano difficili da ottenere e sembravano più probabilità di essere resuscitati, li terrei un po 'più "live" rispetto al controllo del codice sorgente. La gente non lo saprà / ricorderà che esistono - dicendo "si può semplicemente trovarlo nel controllo del codice sorgente" presume che tu sappia / ricordi che è lì! In questi casi, considera la deprecazione (con "assert (false)" showstopper) o commentando.

Se il codice è banale e poco interessante, lo butto via per eliminare l'inerzia inutile del sistema software.

Per i cadaveri di codice interessanti, utilizzo un ramo archive nei miei sistemi di controllo delle versioni.

Un buon motivo per mantenere i metodi non utilizzati è: potrebbero essere utilizzati su altri rami / tag!

Esplora tutti i tuoi rami e tag attivi prima di rimuoverli.

Se usi un sistema di controllo della versione, non preoccuparti dei riferimenti futuri, poiché puoi semplicemente vedere attraverso la cronologia di quel codice e trovare la parte cancellata. Se non lo fai e pensi che un giorno verrebbe usato, allora lascia semplicemente che rimanga lì, ma commentalo con una descrizione che spieghi perché è stato commentato.

Tuttavia, se sei sicuro di non utilizzarlo in futuro, semplicemente rimuovilo . Penso che le ragioni che hai menzionato siano piuttosto semplici per la rimozione del codice.

Ma per favore prima di rimuoverlo, assicurati che non sia usato da nessuna parte. Visual Studio ha una funzione chiamata Trova tutti i riferimenti che ricerca l'intera soluzione e trova qualsiasi riferimento alla variabile, al metodo, alla proprietà, alla classe, all'interfaccia correnti, ecc. Ho sempre la certezza che non ci sia riferimento prima di rimuovere parte del mio codice.

Ho avuto relativamente spesso l'esperienza di trovare una funzione che sembra che farà esattamente quello di cui ho bisogno e mi fido di farlo funzionare da molto tempo, per scoprire che non ha effettivamente stato utilizzato in diversi anni. Il codice che non viene utilizzato non viene mantenuto e, sebbene possa aver funzionato anni fa, l'API è cambiata abbastanza da non potersi fidare di esso.

Al massimo, finisci per spendere un sacco di tempo per assicurarti che faccia ancora ciò che vuoi. Nel peggiore dei casi, sembra funzionare fino a quando non si viene morsi con un brutto baco in un secondo momento e occorre più tempo per rintracciarlo perché si presuppone che il codice "testato in produzione" funzioni in modo che il problema debba essere da qualche altra parte nel nuovo codice. Nella mia esperienza, è quasi sempre più veloce solo scrivere una nuova funzione da solo.

Se lo elimini, ma lo scoprirai relativamente presto ne avrai effettivamente bisogno, è lì nel controllo del codice sorgente. Se non ne hai bisogno fino a quando non è passato molto tempo che non ricordi che è nel controllo del codice sorgente, probabilmente stai meglio scrivendolo da zero comunque.

Niente consuma meno tempo di nessun codice.

Se ti devi immergere in una base di codice, hai bisogno di tempo per capire, per cosa è usato quel codice, e se è usato per niente, ti serve ancora più tempo.

Ok - questo potrebbe essere un commento, ma poi di nuovo, ognuno ragionerà sul motivo per cui questo codice non utilizzato è ancora nella base del codice, se dovrebbe essere rimosso o meno.

Se non c'è nulla, nessuno perderà tempo con esso.

Se è stato difficile farlo correttamente, hai bisogno di una buona documentazione, che questo codice esista, ma se il codebase evolve su alcune iterazioni, forse non funzionerà più, se verrà riattivato.

Rimuovi il codice inutilizzato - meno confusione, migliore comprensione. Il tuo sistema di controllo della versione si prenderà cura di te. Inoltre, se stai utilizzando qualcosa di meglio del blocco note, il tuo ambiente ti consentirà di utilizzare il codice precedente come riferimento.

I commenti lunghi del vecchio codice sono fonte di distrazione e rendono difficile la navigazione.

Saluti

Segui questo semplice algoritmo:

1. Viene eseguito il backup in un SCM? Se sì, passa a 3.
2. Configura un SCM.
3. Getta via la roba .

Tutti i tuoi punti a favore della rimozione sono validi.

Tutti i tuoi punti a favore di mantenere la confusione non sono validi una volta che hai un SCM per cercarlo o ripristinarlo. In realtà, il tuo SCM dovrebbe essere in grado di aiutarti a capire perché quel codice è qui e inutilizzato, se è stato usato correttamente.

Si chiama "codice morto" per un motivo. Lascia morire e riposa in pace.

"Può essere usato come riferimento" Non vorrei essere d'accordo con l'essere un buon motivo per lasciare in codice inutilizzato. Spesso, solo una piccola porzione del codice inutilizzato sta effettivamente dimostrando qualcosa di interessante. Esistono diversi modi per documentare e memorizzare codice utile ma non utilizzato.

Sebbene il controllo della versione conterrà una cronologia che ti permetterà facilmente di ripristinare particolari funzionalità se in seguito deciderà che il codice è necessario, sapendo che devi andare a cercare nella cronologia del controllo della versione per trovare xy o z da chissà cosa precedente la revisione può essere un po 'noiosa e spesso viene trascurata a meno che non si abbia un'idea abbastanza specifica di ciò che si sta cercando.

Il codice potrebbe essere commentato con una nota su quando è stato rimosso e perché non è stato semplicemente eliminato dal codice. Tuttavia, questo è generalmente considerato di cattivo stile, e il codice che non viene usato e non mantenuto correttamente può introdurre tutti i tipi di bug se non viene commentato in seguito, quindi questo è generalmente meglio come una fase di debug / testing temporaneo durante il refactoring medio di un modo per lasciare il codice di produzione.

Il mio modo preferito di memorizzare il codice cancellato, se sembra essere utile in futuro, è di creare un documento di riferimento secondario contenente tutti i vari blocchi di codice cancellato. Ogni blocco di codice è etichettato con una breve menzione di dove proviene o qualcos'altro pertinente da ricordare, ad esempio quando è stato rimosso o il numero di revisione che era l'ultimo nel codice in. Tutto rimosso ma "potenzialmente utile" è in un posto, facilmente ricercabile, ma non richiede uno sforzo costante per mantenere e testare su base continuativa (che il test venga posticipato a qualunque punto venga reintrodotto).

Rimarrà nel controllo del codice sorgente; non dovrebbe rimanere nella base di codice attiva.

L'unica eccezione è se il codice completa il progetto e mentre non si sta usando il codice, si prevede di rendere pubblico il codice e altri potrebbero volere quella funzionalità di base. Quindi, basta progettare i test per assicurarsi che queste parti del codice funzionino in modo tale da imitare il modo in cui si propongono gli altri utenti che potrebbero utilizzare queste parti del codice. Tuttavia, se stai pensando di eliminare il codice e non riesci a trovare una valida ragione per mantenerlo, dovrebbe andare. Il codice non utilizzato rende più lavoro per tutti (più difficile leggere il codice, il codice potrebbe essere danneggiato, più lavoro da mantenere, ecc.)

In base alla mia esperienza, anche la rimozione di codice inutilizzato può ritorcersi contro. Potresti dimenticarti di avere quel codice e non lo cercherai nella storia. O forse non sai nemmeno che qualcuno ha implementato quel codice e poi lo ha rimosso in seguito. Di nuovo, non lo cercherete nella storia ...

Senza dubbio, avere un codice inutilizzato è un cattivo odore.

AGGIORNAMENTO: Ho appena notato che Ed Staub ha dato una risposta molto simile.