# Revisione codice con IA: checker gratuito per il diff URL: https://codebasechat.com/it/tools/revisione-codice-con-ia Type: tool Locale: it Published: 2026-11-04 Updated: 2026-11-05 --- > Incolla un git diff o uno snippet e ricevi un punteggio su 100 con i risultati per riga: segreti, SQL insicuro, catch vuoti, debug dimenticati, modifiche troppo grandi. Gira nel browser. ## Controlla il tuo diff prima che lo faccia un revisore Incolla un git diff o uno snippet. Questa revisione codice con IA gratuita è un checker a regole, non un modello: segnala nel browser segreti, SQL insicuro, errori ignorati, codice di debug dimenticato e modifiche troppo grandi, e assegna alla pull request un punteggio su 100. ## Verificatore pre-review del diff Incolla un diff unificato o un codice qualsiasi. Se viene rilevato un diff, vengono controllate solo le righe aggiunte. Niente di ciò che incolli lascia il tuo browser. *[Interactive widget — see the live page for the full experience]* ## Cosa guarda il checker e cosa ignora ### Solo le righe aggiunte Se incolli un diff unificato, il checker legge le intestazioni degli hunk, conta i numeri di riga nel file nuovo e analizza solo le righe che hai aggiunto. Le righe rimosse e il contesto invariato non generano mai un risultato, quindi non viene attribuito a te codice vecchio. ### Punteggio pesato per gravità Le tredici regole sono divise in tre livelli. Alta costa 15 punti: segreti hardcoded, eval, SQL costruito con stringhe, controlli TLS disattivati. Media costa 7: eccezioni ignorate, test focalizzati, innerHTML, un diff da 400 righe. Bassa costa 2: TODO, print di debug, codice commentato. Ogni regola conta al massimo tre volte. ### Controlli su dimensione e test Oltre 200 righe aggiunte ricevi un invito a dividere la modifica, oltre 400 un invito più deciso. Questo segue lo studio SmartBear su Cisco: la qualità della revisione cala quando un revisore affronta più di 200-400 righe alla volta. Anche un diff con più di 50 righe aggiunte e nessun file di test viene segnalato. ## Dal paste a una pull request pulita in quattro passaggi 1. **Incolla il diff** — Esegui git diff main...HEAD, oppure git diff --staged prima del commit, e incolla l'output. Funziona anche uno snippet semplice, ma perdi i nomi dei file e il rilevamento dei file di test. 2. **Leggi prima i risultati alti** — Gli elementi rossi sono quelli su cui un revisore si fermerà. Una chiave hardcoded in un commit resta nella cronologia anche dopo aver eliminato la riga, quindi ruotala, non limitarti a rimuoverla. 3. **Correggi o giustifica il resto** — Ogni risultato include una correzione in una riga. Se una segnalazione è un falso positivo, scrivilo nella descrizione della PR. Così il revisore non dovrà porre la stessa domanda. 4. **Copia la checklist** — Il pulsante di copia trasforma i risultati in una checklist Markdown da incollare nel corpo della PR, così il revisore vede cosa hai già individuato. *Perché un pre-check* ## I primi trenta secondi di una revisione non dovrebbero andare su console.log Apri una pull request di un collega e conosci la routine. Scorri il diff, noti un print di debug dimenticato, un TODO senza ticket, un test saltato e un blocco catch che inghiotte l'errore. Nessuna di queste cose richiede una persona. Serve una checklist che giri prima che la richiesta venga inviata. È questo il vuoto che lo strumento colma. L'attenzione di un revisore è limitata: lo studio SmartBear sulle revisioni Cisco ha rilevato che la capacità di trovare difetti regge quando si rivedono da 200 a 400 righe in 60-90 minuti, e cala oltre. Ogni minuto speso sui problemi meccanici è un minuto in meno dedicato alle domande che solo una persona può porre: è l'approccio giusto, si adatta all'architettura, avrà ancora senso tra sei mesi? Non sostituisce un revisore, e non finge di farlo. Elimina le obiezioni banali, così la revisione umana parte dalla parte interessante. - Individua i problemi meccanici prima che parta la richiesta di revisione - Assegna a ogni risultato un numero di riga preso dalle intestazioni del diff - Gira in locale, quindi è sicuro incollarci codice proprietario ## Domande sul checker ### È un revisore di codice con IA o un linter? Né l'uno né l'altro, in senso stretto. È un checker pre-review basato su regole. Nessun modello legge il tuo codice e non viene generato nulla. Tredici regole su pattern analizzano le righe aggiunte alla ricerca di ciò che un revisore nota nei primi trenta secondi: segreti, SQL insicuro costruito con stringhe, eccezioni ignorate, output di debug dimenticato. Lo dichiariamo apertamente, perché un revisore con IA che indovina è peggio di una checklist che non lo fa. ### Il mio codice lascia il browser? No. I controlli girano in JavaScript su questa pagina. Non c'è alcun upload, nessuna chiamata API e nessun account. L'unica cosa registrata è un evento anonimo che indica l'uso dello strumento, senza alcun contenuto della casella di testo. ### Da dove vengono le regole sulle 200-400 righe e sul file di test? La soglia di dimensione segue lo studio SmartBear sui dati di revisione di Cisco, che raccomanda di non rivedere più di 200-400 righe alla volta. La regola sulle piccole modifiche segue le pratiche ingegneristiche pubbliche di Google sulle CL piccole. La regola sul test mancante è una nostra convenzione: un diff con più di 50 righe aggiunte e nessun file di test viene segnalato, perché è una domanda che i revisori si pongono comunque. ### Come viene calcolato il punteggio? Parte da 100. Ogni risultato sottrae punti in base alla gravità: 15 per alta, 7 per media, 2 per bassa. Ogni regola conta al massimo tre volte, così una regola rumorosa non può azzerare il punteggio. È una convenzione per ordinare il lavoro, non una misura della qualità del codice. Un punteggio di 100 significa che nessuna regola è scattata, non che il codice sia corretto. ### Cosa non rileva? Tutto ciò che richiede comprensione: logica di business sbagliata, race condition, un'astrazione errata, un'API che non invecchierà bene. Le regole basate su regex producono anche falsi positivi, ad esempio un fixture di test che contiene una password finta. Tratta ogni risultato come una domanda a cui rispondere, non come un verdetto. ### Con quali linguaggi funziona? Le regole sono pattern di testo, quindi funzionano su JavaScript, TypeScript, Python, Java, Go e la maggior parte del codice della famiglia C. Alcune regole sono specifiche per linguaggio: bare except è Python, System.out.println è Java, InsecureSkipVerify è Go. Incolla un git diff unificato e i numeri di riga vengono dalle intestazioni degli hunk. ### È gratuito? Sì, senza registrazione. Se mentre fai la revisione vuoi risposte sul resto del repository, ad esempio chi chiama questa funzione o dove viene letto un valore di configurazione, è a questo che serve codebasechat. ## Rivedi con tutto il repository davanti Un diff mostra cosa è cambiato, non cosa tocca. codebasechat risponde a domande sul tuo codice in linguaggio naturale, così puoi verificare chi chiama la funzione modificata prima di approvare. *Call to action: Prova codebasechat gratis* ## FAQ ### È un revisore di codice con IA o un linter? Né l'uno né l'altro, in senso stretto. È un checker pre-review basato su regole. Nessun modello legge il tuo codice e non viene generato nulla. Tredici regole su pattern analizzano le righe aggiunte alla ricerca di ciò che un revisore nota nei primi trenta secondi: segreti, SQL insicuro costruito con stringhe, eccezioni ignorate, output di debug dimenticato. Lo dichiariamo apertamente, perché un revisore con IA che indovina è peggio di una checklist che non lo fa. ### Il mio codice lascia il browser? No. I controlli girano in JavaScript su questa pagina. Non c'è alcun upload, nessuna chiamata API e nessun account. L'unica cosa registrata è un evento anonimo che indica l'uso dello strumento, senza alcun contenuto della casella di testo. ### Da dove vengono le regole sulle 200-400 righe e sul file di test? La soglia di dimensione segue lo studio SmartBear sui dati di revisione di Cisco, che raccomanda di non rivedere più di 200-400 righe alla volta. La regola sulle piccole modifiche segue le pratiche ingegneristiche pubbliche di Google sulle CL piccole. La regola sul test mancante è una nostra convenzione: un diff con più di 50 righe aggiunte e nessun file di test viene segnalato, perché è una domanda che i revisori si pongono comunque. ### Come viene calcolato il punteggio? Parte da 100. Ogni risultato sottrae punti in base alla gravità: 15 per alta, 7 per media, 2 per bassa. Ogni regola conta al massimo tre volte, così una regola rumorosa non può azzerare il punteggio. È una convenzione per ordinare il lavoro, non una misura della qualità del codice. Un punteggio di 100 significa che nessuna regola è scattata, non che il codice sia corretto. ### Cosa non rileva? Tutto ciò che richiede comprensione: logica di business sbagliata, race condition, un'astrazione errata, un'API che non invecchierà bene. Le regole basate su regex producono anche falsi positivi, ad esempio un fixture di test che contiene una password finta. Tratta ogni risultato come una domanda a cui rispondere, non come un verdetto. ### Con quali linguaggi funziona? Le regole sono pattern di testo, quindi funzionano su JavaScript, TypeScript, Python, Java, Go e la maggior parte del codice della famiglia C. Alcune regole sono specifiche per linguaggio: bare except è Python, System.out.println è Java, InsecureSkipVerify è Go. Incolla un git diff unificato e i numeri di riga vengono dalle intestazioni degli hunk. ### È gratuito? Sì, senza registrazione. Se mentre fai la revisione vuoi risposte sul resto del repository, ad esempio chi chiama questa funzione o dove viene letto un valore di configurazione, è a questo che serve codebasechat.