Rileva codice morto prima del merge.

Scopri come codice morto entra in una revisione local-first, quali evidenze produce Code Radar, dove finisce la copertura e come portare finding affidabili in CI.

Controlla questo rischio in locale Rivedi le prove di rilevamento

radar scan . --quick

Cosa significa codice morto qui.

La regola codice morto individua pattern che possono creare rischio sfruttabile o nascondere debito rilevante e restituisce posizione, severità, confidenza e rimedi.

Riferimento regola

Prova da ispezionare

Usa «Rileva codice morto prima del merge.» come ambito della decisione: verifica input, dettaglio dei finding, passaggio del workflow e confini del prodotto prima di installare o acquistare.

CriterioProva da ispezionareConfine

Ambito di inputFile selezionati, configurazione, modalità e regole attive.Sono valutati solo percorsi e controlli inclusi.

Dettaglio findingFile, riga, ID regola, gravità, spiegazione e riparazione.L'output illustrativo non è un risultato del tuo repository.

Passaggio del workflowRisultato locale, report, contesto agente e segnale CI opzionale.Abilita export o CI solo quando servono al workflow.

Fit decisionaleApplica gli stessi criteri a un repository reale prima di scegliere.Non viene dichiarato un vincitore universale né un risultato garantito.

Riferimento regola

Controlla questo rischio in locale

Copertura e segnali concreti

Per codice morto, controlla l'ambito concreto sotto invece di affidarti a una sola categoria. Focus: salute del codice; RADAR-HEALTH-DEAD, salute del codice.

Pubblico: sviluppatori che devono capire questo rischio prima del merge: codice morto.
Evidenze da controllare prima di fidarsi del risultato.: File esatto, contesto regola, severità, confidenza e indicazioni di rimedio. RADAR-HEALTH-DEAD, salute del codice. Output terminale e artefatti SARIF, JSON o HTML generati dallo stesso insieme di finding.
Confine: Il rilevamento statico è evidenza, non prova di sfruttabilità. Controlla flusso dati e contesto, documenta i falsi positivi e testa il comportamento corretto.
ID regola: RADAR-HEALTH-DEAD

Pattern rischioso / Pattern più sicuro

codice morto: Un risultato utile deve essere spiegabile a uno sviluppatore e trasferibile al passaggio successivo. Controlla queste evidenze prima di cambiare la policy del team.

Pattern rischiosoPattern più sicuro

if (false) { runLegacyPath(); }removeUnusedLegacyPath();

Dal segnale locale al gate condiviso.

codice morto: Usa il flusso minimo che dimostra valore. Ogni passaggio successivo deve riutilizzare evidenze che il team già comprende. File esatto, contesto regola, severità, confidenza e indicazioni di rimedio. RADAR-HEALTH-DEAD, salute del codice. Output terminale e artefatti SARIF, JSON o HTML generati dallo stesso insieme di finding.

PassoComando o azioneDecisione

1Eseguire una scansione locale rapidaIl segnale è utile?

2Controllare e correggere i findingLa correzione è specifica e riproducibile?

3Esportare evidenze portabiliIl reviewer richiede SARIF, JSON o HTML?

4Portare la soglia affidabile in CIQuale severità deve bloccare una pull request?

radar scan . --quick
radar scan . --format sarif --fail-on high

Fonte ufficiale

Fonti primarie

Valida il workflow sul tuo codice.

Applica le prove di questa pagina a un repository reale. Per «Rileva codice morto prima del merge.», conferma quale finding viene prodotto, se il passo successivo è riproducibile e dove scansione locale, report, agenti o CI devono fermarsi o ampliarsi.