Ricerca di codice inutilizzato (ovvero "morto") in Delphi

Question

Esistono strumenti che possono determinare se si utilizza una funzione/procedura/metodo/intera classe?

Ho visto strumenti che possono aiutare uno sviluppatore esperto a rintracciare frammenti di codice inutilizzati (la maggior parte sono per lingue diverse da Delphi) ma la maggior parte ha una curva di apprendimento ripida e/o richiede un considerevole scavo per determinare se un frammento di codice è usato o no

Lo smart linker di Delphi presumibilmente lo fa per ridurre le dimensioni dell'eseguibile finale. Sfortunatamente le poche informazioni fornite sullo smart linker non indicano un modo per recuperare ciò che è stato eliminato dall'hurd.

Certamente, anche se è possibile scoprire cosa sta eliminando lo smart linker, potrebbe essere molto prudente con il suo abbattimento.

Answer 1

Sebbene goffi e non globali, è possibile esaminare il codice sorgente per i punti sul margine, come mostrato di seguito. Queste sono linee su cui è possibile impostare i punti di interruzione perché il codice non è stato eliminato.

Questo succede, credo, al livello della procedura. Non conosco un modo per determinare questo a un livello meno volgare.

Answer 2

Questo thread discute smontaggio di inutilizzati, e parla di strumenti come Icaro Pascal Analyzer. Quello strumento farà tutto il necessario e altro ancora. How to "automatically" remove unused units from uses clause?

Answer 3

Controlla gli strumenti a http://www.peganza.com/ per aiutare con alcune delle tue attività.

Icaro è freeware e analizza le clausole di "utilizzo" per consentire di rimuovere riferimenti inutilizzati.

Pascal Analyzer è la versione completa che include la funzionalità Icarus e una tonnellata di altri strumenti.

Answer 4

Forse CodeHealer potrebbe aiutarvi con il codice non utilizzato

CodeHealer esegue analisi del codice sorgente in modo approfondito, alla ricerca di problemi nelle seguenti aree:

Audit: regole di controllo della qualità come codice inutilizzato o irraggiungibile, uso dei nomi e delle parole chiave di Delphi come identificatori , identificatori che nascondono altri con lo stesso nome in un ambito più elevato, e altro ancora. Controlli: potenziali errori quali non inizializzate o senza riferimenti identificatori, tipo pericoloso colata, conversioni di tipo automatico, valori funzione di ritorno indefiniti, inutilizzati valori assegnati, e altro ancora. Metriche: Quantificazione di proprietà del codice come ciclomatica complessità, accoppiamento tra oggetti (Data Abstraction accoppiamento), commentare rapporto , numero di classi, linee di codice, e altro ancora.

Answer 5

È possibile utilizzare uno strumento Code Coverage per trovare il codice non utilizzato.Basta eseguire l'applicazione ed eseguire tutte le parti manualmente. Il rapporto sulla copertura del codice mostrerà quali parti non sono state toccate. (L'esecuzione dello strumento sui test dell'unità non è utile perché il codice non utilizzato può ancora avere test delle unità).

Uno strumento di copertura del codice gratuito (open source) per Delphi è disponibile here. Dopo averlo eseguito, controlla le linee rosse nei report, queste sono le linee che non sono state raggiunte.

Delphi Code Coverage è un semplice strumento di copertura di codice per Delphi che crea rapporti di copertura del codice in base a file mappa dettagliata.

Per ogni unità ci sarà un unit.html con una sintesi della copertura , seguita dalla sorgente marcato. Le linee verdi erano coperte. Le linee rosse non erano linee coperte. Le altre linee non hanno generato il codice per questo. Esiste anche un file CodeCoverage_summary.html che riepiloga la copertura e contiene i collegamenti ai report delle unità generate.

Forse l'autore può aggiungere una funzione di 'ricerca di codice guasto' in una versione futura.

Answer 6

Si potrebbe anche verificare lo strumento profiler/copertura commerciale più comunemente usato, AQTime da http://www.automatedqa.com

Ecco un video sulle caratteristiche: http://www.automatedqa.com/products/aqtime/screencasts/coverage-profiling/

Answer 7

Per le unità, utilizzare Pascal Analyzer. Potrebbe essere necessario usarlo più volte.

Per oggetti/classi registrati nelle fabbriche di classi (e simili), sarà necessario ricontrollare manualmente, poiché saranno completamente compilati. La ragione di ciò è che il compilatore non sa se effettivamente li uso o meno.

Per i metodi, è necessario verificare i punti blu. Non molto pratico, quindi c'è un altro modo (da quello che mi è stato detto quando indago sullo stesso argomento). È necessario eseguire una compilazione completa con un file di mappa dettagliato abilitato. Una volta fatto, è necessario confrontare la fonte per vedere se c'è una voce nel file della mappa. In caso contrario, il codice non viene compilato - codice probabilmente possibile (probabilmente perché se si tratta di componente, potrebbe essere che non si usi tale funzionalità).

Answer 8

In passato ho compilato le fonti con Free Pascal utilizzando la funzionalità "genera assemblatore" e quindi ho creato alcuni semplici programmi di filtro che operano sulla sorgente. (Per questo bit è utile sapere che smartlinking viene fatto usando il linker "sezione" granularità)

A volte ti dà intuizioni perché certe cose non sono smartlinked fuori (ad esempio perché non v'è un riferimento in qualche tabella che potrebbe essere accesso da qualcosa in un'inizializzazione)

Ovviamente Delphi non è FPC, ma quando si hanno suggerimenti su cosa cercare, si tratta di osservare i punti nel margine dopo la compilazione di Delphi per vedere se è collegato in modo intelligente o no. Allo stesso modo, se ti chiedi perché un determinato codice sia stato (non) scollegato in modo intelligente, analizzare un piccolo programma di esempio compilato per assemblatore con FPC può rendere evidente la ragione. (per esempio.trovate tabelle RTTI con riferimento ad esso)

Il percorso FPC consente un percorso sistematico per la ricerca di candidati per tali test.