Modi efficaci per gestire gli avvisi dell'analizzatore statico causati dall'uso incidentale della riflessione

0

Normalmente non uso la reflection direttamente durante la programmazione in Java. Ma io uso API e framework che si basano internamente su riflessioni o annotazioni per fornire punti di personalizzazione.

Molti framework utilizzano annotazioni per impostare l'iniezione di dipendenza o eseguire una sorta di cablaggio logico automatico per conto dell'utente.

Ciò comporta un sacco di accessi al campo, al metodo e al costruttore che l'analizzatore di codice statico non può seguire, causando molti falsi positivi (non solo avvertimenti "metodo / campo non utilizzato"). La mia unica opzione realistica per continuare a sopprimere questi avvertimenti o ci sono altre cose che posso fare per aiutare l'analizzatore a capire meglio i veri punti di ingresso delle mie classi?

Ho sentito alcune persone discutere di utilizzare il codice di test per questo scopo.

In molti casi, I potrebbe probabilmente scrivere casi di test rilevanti che fanno scomparire gli avvertimenti, ma sono preoccupato per il numero piuttosto elevato di casi in cui ciò implicherebbe la verifica dei dettagli di implementazione invece di comportamento osservabile. Questo codice ha già una copertura adeguata e non voglio scrivere test che mi pentirò di scrivere ogni volta che eseguo la manutenzione. Ma se il test di whitebox è davvero a volte l'alternativa "migliore", ci sono modi per ridurre al minimo gli aspetti negativi? La fragilità e la perdita di implementazione sono le mie preoccupazioni principali.

    
posta Tim Seguine 17.05.2018 - 17:30
fonte

1 risposta

1

Quando si utilizzano le funzioni dinamiche (riflessione, downcast, metaprogrammazione, generazione di codice, linguaggi di scripting) c'è una comprensione implicita che si sacrifica volontariamente l'analisi statica per comodità di codifica. C'è definitivamente un compromesso qui.

Per molti progetti, questo non è un buon affare. O forse è stata una buona idea all'inizio del progetto, ma ora è diventata un problema di manutenzione. Quando il controllo dei tipi, il supporto IDE e l'analisi statica sono più preziosi della convenienza, potrebbe essere utile riscrivere le parti rilevanti per evitare le caratteristiche dinamiche.

Questo non è sempre possibile o desiderabile. Alcuni problemi sono intrinsecamente dinamici. Per alcuni progetti, scrivere un boilerplate in più sarebbe un onere di manutenzione maggiore rispetto al supporto di strumenti incompleto. Nel tuo caso, continuare a disabilitare alcuni controlli di analisi statici potrebbe essere il meglio che puoi fare.

Mentre la scelta tra espressività e analisi statica è generalmente esclusiva, potrebbe esserci una terza opzione: migliorare i tuoi strumenti. Nel caso di Java, potresti forse scrivere annotazioni che i tuoi strumenti di analisi statica comprendono.

    
risposta data 21.05.2018 - 23:23
fonte

Leggi altre domande sui tag