SonarQube per controllare e migliorare il tuo codice

Luca Terribili

22 Ottobre 2025

SonarQube non è un semplice analizzatore statico, è una specie di specchio brutale per chi programma. Gli dici "guarda qui", e lui ti dice senza pietà quanto è marcio il tuo codice, dove stai accumulando debito tecnico, quante porcate hai lasciato in giro e quanto ti costerà rifarle quando sarà troppo tardi. È un sistema che legge il tuo codice riga per riga e ne valuta la qualità, la sicurezza e la manutenibilità.

Lo fa in modo automatico e continuo, come un check-up costante dentro la pipeline CI/CD. Non è uno strumento che usi una volta e poi dimentichi: è un guardiano permanente che monitora ogni singola modifica, ogni commit, ogni merge request. E la cosa bella è che non aspetta che tu gli chieda un parere: te lo dà, sempre, senza filtri.

Funziona con quasi tutti i linguaggi moderni: Java, PHP, JavaScript, TypeScript, Python, Go, C#, e si integra perfettamente con i tool che usi già. Se lavori con IntelliJ, PhpStorm, WebStorm o PyCharm, puoi attaccarci SonarLint, il suo fratellino locale, così vedi gli errori e i difetti direttamente nell'IDE mentre scrivi. Quando poi il codice entra in SonarQube, viene sezionato, analizzato e classificato in tre grandi categorie di problemi: bug, vulnerabilità e code smells.

Bug: quando il codice mente a se stesso

I bug sono difetti logici o sintattici che possono causare comportamenti errati o crash. SonarQube li riconosce grazie a regole linguistiche precise e a modelli di flusso. Ti segnala il metodo che non restituisce mai, l'eccezione mai gestita, il null pointer possibile, la logica che non termina. Ti fa capire che magari il codice funziona oggi, ma domani ti esploderà in faccia.

Questi problemi sono subdoli perché spesso non si manifestano immediatamente. Il codice compila, i test passano (quando ci sono), ma nascosto tra le righe c'è un difetto che aspetta solo le condizioni giuste per emergere. SonarQube li intercetta prima che arrivino in produzione, analizzando il flusso di esecuzione e le condizioni logiche che hai scritto.

Esempi di bug comuni

Java - Null Pointer potenziale:

public String getUserEmail(Long userId) {
    User user = userRepository.findById(userId);
    return user.getEmail().toLowerCase(); // Bug: user potrebbe essere null
}

Python - Divisione per zero non gestita:

def calculate_average(total, count):
    return total / count  # Bug: count potrebbe essere 0

TypeScript - Promise non gestita:

async function loadUser(id: string) {
    fetchUserData(id); // Bug: Promise ignorata, errori non catturati
    console.log('Loading complete');
}

PHP - Variabile potenzialmente non definita:

function getDiscount($user) {
    if ($user->isPremium()) {
        $discount = 20;
    }
    return $discount; // Bug: $discount non definita se l'utente non è premium
}

Vulnerabilità: le porte aperte che non vedi

Le vulnerabilità invece sono falle di sicurezza. Parliamo di SQL injection, XSS, input non sanitizzato, configurazioni errate, segreti nel codice o dipendenze a rischio. È la parte più utile se lavori in un contesto dove la sicurezza conta, perché SonarQube incrocia le regole OWASP e ti indica la gravità del rischio, la probabilità di exploit e la parte esatta del codice da sistemare.

Qui non si parla più di "potrebbe crashare", si parla di "qualcuno potrebbe entrare e fare danni". Le vulnerabilità sono i regali che fai agli attaccanti, le chiavi che lasci sotto lo zerbino. SonarQube le identifica confrontando il tuo codice con pattern di attacco noti e best practice di sicurezza consolidate. Ti dice non solo cosa è sbagliato, ma anche come sistemarlo.

Injection flaws

Le injection flaws si verificano quando un’applicazione accetta input esterni e li passa direttamente a un interprete o a un comando senza validazione o sanitizzazione. Il caso più classico è la SQL Injection, dove l’input dell’utente finisce dentro una query SQL concatenata come stringa, permettendo l’esecuzione di comandi arbitrari sul database. Lo stesso vale per Command Injection (esecuzione di comandi di sistema) o LDAP Injection (alterazione di query LDAP). Queste vulnerabilità sono estremamente gravi perché possono portare all’accesso o alla distruzione dei dati, all’esecuzione di codice non autorizzato e al controllo completo del sistema.

Cross-Site Scripting (XSS)

Il Cross-Site Scripting avviene quando l’applicazione inserisce input dell’utente nel DOM o nella pagina HTML senza filtrarlo o codificarlo correttamente. Questo consente a un attaccante di iniettare codice JavaScript malevolo che viene eseguito nel browser della vittima. Gli effetti vanno dal furto di cookie e sessioni fino al controllo completo dell’interfaccia utente. Esistono vari tipi di XSS: riflesso, memorizzato e DOM-based, quest’ultimo spesso derivante da manipolazioni dirette del DOM in JavaScript o Angular senza escape dell’input.

Broken Authentication

La Broken Authentication riguarda la gestione insicura delle sessioni o delle credenziali. Include l’uso di session ID prevedibili, l’assenza di invalidazione dopo il logout, la memorizzazione di password in chiaro o l’uso di meccanismi di autenticazione non protetti. Anche l’uso errato dei token JWT o di cookie senza flag HttpOnly e Secure rientra in questa categoria. Il risultato può essere la compromissione dell’identità degli utenti o l’accesso non autorizzato a risorse sensibili.

Sensitive Data Exposure

La Sensitive Data Exposure si verifica quando dati sensibili — come password, chiavi API, token o dati personali — vengono esposti in chiaro o salvati nel codice, nei log o nei file di configurazione. Anche il mancato uso di cifratura in transito (HTTPS) o a riposo (crittografia su database o file system) rientra in questa categoria. Un errore tipico è il token hardcoded nel sorgente o la password salvata in una variabile visibile nel front-end.

Security Misconfiguration

La Security Misconfiguration nasce da impostazioni errate o eccessivamente permissive nei sistemi, framework o server. Un esempio classico è mantenere il debug mode attivo in produzione, che espone informazioni sensibili sull’ambiente o sullo stack. Altri esempi includono CORS troppo permissivi, directory listing attivo, header di sicurezza mancanti o error handling che mostra dettagli del server. È una delle vulnerabilità più comuni perché dipende spesso da disattenzioni operative.

Insecure Dependencies

Le Insecure Dependencies sono librerie, pacchetti o framework che contengono vulnerabilità note e non vengono aggiornati. Se l’applicazione fa affidamento su una dipendenza compromessa, eredita automaticamente il rischio. Strumenti come SonarQube, npm audit o Composer audit rilevano queste falle analizzando le versioni delle librerie rispetto ai database CVE pubblici. Tenere aggiornato l’ecosistema è una parte essenziale della sicurezza applicativa.

Insufficient Logging

L’Insufficient Logging indica che l’applicazione non registra in modo adeguato gli eventi critici di sicurezza. Senza log completi e centralizzati non è possibile rilevare tentativi di intrusione, analizzare incidenti o effettuare audit. Gli errori comuni includono l’assenza di log per accessi falliti, modifiche ai privilegi o eccezioni gravi. Una buona pratica è implementare logging strutturato, correlato a un sistema di monitoraggio (ELK, Graylog, Splunk) e con retention adeguata.

Esempi di vulnerabilità

PHP - SQL Injection:

function getUser($username) {
    $query = "SELECT * FROM users WHERE username = '$username'";
    return mysqli_query($conn, $query); // Vulnerabilità: SQL injection
}

Java - Path Traversal:

public File readUserFile(String filename) {
    return new File("/uploads/" + filename); // Vulnerabilità: path traversal
}

TypeScript - XSS:

function displayMessage(msg: string) {
    document.getElementById('output').innerHTML = msg; // Vulnerabilità: XSS
}

Python - Hardcoded credentials:

def connect_db():
    password = "admin123"  # Vulnerabilità: credenziali nel codice
    return psycopg2.connect(host="localhost", password=password)

Code Smells: Quanto il tuo codice "puzza"

I code smells sono segnali di cattiva progettazione o di degrado del codice che non rappresentano necessariamente un errore di funzionamento, ma indicano che qualcosa nel design o nella struttura non è ottimale e potrebbe generare problemi di manutenzione, estendibilità o leggibilità nel tempo. Si tratta di difetti sottili ma importanti, perché rendono il codice più difficile da comprendere e aumentano il rischio di introdurre bug quando lo si modifica. I code smells non bloccano l’esecuzione del programma, ma compromettono la qualità complessiva del software.

La classe troppo grande è un altro code smell frequente. Si manifesta quando una singola classe concentra troppi compiti e viola il principio di responsabilità unica (Single Responsibility Principle). Il risultato è un oggetto che diventa centrale e fragile, poiché una modifica in una parte può avere effetti indesiderati su altre. Separare le responsabilità in più classi più coese rende il sistema più modulare e stabile. Un odore simile è il data clump, ossia l’uso ripetuto degli stessi gruppi di variabili in più punti, che suggerisce la necessità di creare un oggetto o una struttura dati dedicata.

Anche le dipendenze circolari o eccessivamente strette tra moduli rappresentano un forte code smell. Quando due componenti conoscono troppo l’uno dell’altro, diventa impossibile modificarne uno senza toccare l’altro. Ciò limita l’evoluzione del progetto e rende complesso il test. L’introduzione di interfacce, astrazioni o pattern come l’inversione delle dipendenze aiuta a spezzare questi legami. Altri odori correlati sono le classi piene di switch o if annidati, che spesso nascondono la mancanza di polimorfismo o di pattern adeguati (ad esempio Strategy o State).

Un’altra categoria riguarda la gestione dei dati e dei metodi. Il feature envy si manifesta quando un metodo accede più ai dati di un altro oggetto che ai propri, segno che quella logica probabilmente appartiene all’altra classe. Il data class, invece, è una classe che contiene solo campi e getter/setter senza alcuna logica, il che la rende passiva e spesso segnale di un design poco orientato agli oggetti. C’è poi il long parameter list, ossia metodi che richiedono troppi parametri, spesso sintomo che andrebbero raggruppati in una struttura o oggetto più coerente.

Anche l’uso eccessivo di commenti può essere un code smell. Un commento non è di per sé un difetto, ma se serve a spiegare cosa fa un blocco di codice troppo complicato, significa che quel codice non è sufficientemente chiaro e dovrebbe essere rifattorizzato. Il codice leggibile non ha bisogno di spiegazioni ridondanti, ma di nomi espliciti, funzioni brevi e responsabilità chiare. Infine, la presenza di codice morto (variabili mai usate, metodi non richiamati, import inutili) è un odore che indica scarsa pulizia del progetto e aumenta il rumore visivo e cognitivo.

Uno dei code smell più diffusi è la duplicazione del codice, ovvero quando lo stesso frammento logico viene copiato in più punti dell’applicazione invece di essere incapsulato in una funzione riutilizzabile. Questa pratica aumenta la difficoltà di mantenimento, perché ogni modifica deve essere ripetuta in più luoghi, con il rischio di introdurre incoerenze.

Queste metriche sono fondamentali: ti dicono non solo quanto funziona il tuo progetto, ma quanto sarà facile o difficile mantenerlo tra sei mesi. Un codice con il 5% di duplicazione è gestibile, uno con il 30% è un incubo. Una funzione con complessità ciclomatica di 3 è leggibile, una con 25 è un labirinto. E se la copertura dei test è sotto il 50%, stai navigando a vista senza rete di sicurezza.

Brain Over Load: Quando il tuo codice è troppo complesso

Sì, quello di cui parli si chiama "Cognitive Complexity" — ed è esattamente il tipo di errore o warning che SonarQube segnala come “troppa complessità cognitiva” o “brain over load”, in gergo. In pratica indica che un metodo, una funzione o un blocco di codice è troppo difficile da leggere, capire o mantenere, anche se tecnicamente funziona.

SonarQube assegna un punteggio di complessità cognitiva (Cognitive Complexity Score): più il codice ha ramificazioni logiche, condizioni annidate o flussi non lineari, più il punteggio cresce. Se supera una certa soglia (di solito 15 o 20), SonarQube lo segnala come problema.

Vediamo come funziona il punteggio di complessa cognitiva:

introduci un if, for, while, switch, ecc., aumenta di 1;
annidi condizioni (if dentro if, loop dentro loop), aggiunge punti extra;
usi return anticipati, continue, break, catch, ternari complessi, o operatori logici concatenati, aggiungi altri punti;
mantieni il flusso piatto (pochi livelli di indentazione, early return semplici), il punteggio resta basso.

Prendiamo un pezzo di codice in Java:

public void process(User user) {
    if (user != null) {
        if (user.isActive()) {
            for (Order o : user.getOrders()) {
                if (o.isPaid()) {
                    if (o.hasDiscount()) {
                        applyDiscount(o);
                    } else {
                        if (o.getTotal() > 100) {
                            addBonusPoints(user);
                        }
                    }
                } else {
                    sendReminder(o);
                }
            }
        } else {
            deactivate(user);
        }
    }
}

Questo codice funziona, ma SonarQube lo segnalerà come ad alta complessità cognitiva. Vediamo i punti dove accumula punteggio:

if (user != null) → +1
if (user.isActive()) → +1 (+1 di nesting, totale 3)
for (...) → +1 (+1 nesting, totale 5)
if (o.isPaid()) → +1 (+1 nesting, totale 7)
if (o.hasDiscount()) → +1 (+1 nesting, totale 9)
else con if (o.getTotal() > 100) → +2 (uno per else + uno per condizione, totale 11)
else esterno sendReminder(o) → +1 (totale 12)
else deactivate(user) → +1 (totale 13)

Totale: 13 punti. In un progetto reale, se SonarQube è configurato con soglia 10, questo metodo verrebbe segnalato come troppo complesso (overbrain).

Per abbassare il punteggio, bisogna ridurre il nesting e semplificare il flusso logico:

public void process(User user) {
    if (user == null || !user.isActive()) {
        deactivate(user);
        return;
    }

    for (Order o : user.getOrders()) {
        if (!o.isPaid()) {
            sendReminder(o);
            continue;
        }

        if (o.hasDiscount()) {
            applyDiscount(o);
            continue;
        }

        if (o.getTotal() > 100) {
            addBonusPoints(user);
        }
    }
}

Ora la complessità cognitiva scende drasticamente (da 13 a circa 5). Il codice è più lineare, più leggibile, e SonarQube non lo segnala più.

Quality Gates: la disciplina automatizzata

La forza di SonarQube è che tutto questo non lo fa una tantum: lo fa sempre. Ogni commit, ogni merge request, ogni build può passare sotto i suoi occhi. E se imposti i Quality Gates, puoi far fallire la pipeline quando la qualità scende sotto le soglie che tu decidi. In pratica: "se la copertura dei test è sotto l'80% non si rilascia niente", oppure "se c'è una nuova vulnerabilità bloccante, la build muore".

È la forma più pura di disciplina automatizzata. Non c'è spazio per le scuse, per il "lo sistemo dopo", per il "tanto è solo una piccola modifica". Il Quality Gate è un muro: o il codice passa, o resta fuori. E questo cambia radicalmente la cultura del team, perché nessuno vuole essere quello che blocca il rilascio con codice scadente.

Integrazione e utilizzo pratico

Integrarlo non è complicato: installi il server, lo colleghi al tuo progetto e fai girare il "Sonar Scanner". In pochi minuti hai una dashboard visiva che ti mostra l'indice di qualità globale, i problemi divisi per tipo e la cronologia dei miglioramenti. Da lì puoi iniziare a sistemare, rilasciare e monitorare.

Ogni refactoring migliora i punteggi, e ti accorgi che il codice non solo funziona, ma respira meglio. La dashboard diventa una mappa: vedi dove sei, dove devi andare e quanto manca per arrivarci. E quando finalmente raggiungi quel rating A su tutto il progetto, capisci che non stai solo scrivendo software, stai costruendo qualcosa che durerà.

Conclusione: il codice che vive e quello che muore

SonarQube diventa così una specie di revisore costante, un architetto invisibile che ti fa capire dove stai scrivendo male e perché. Ti aiuta a combattere l'abitudine di "va bene così" e quella tentazione quotidiana del "funziona, non toccarlo". Non serve avere un codice perfetto, serve avere un codice sano.

E SonarQube, con il suo occhio clinico, ti mostra la differenza tra il codice che vive e quello che muore sotto il peso del proprio overbrain. Ti insegna che la vera intelligenza non sta nello scrivere codice complicato che solo tu capisci, ma nel creare soluzioni eleganti che chiunque possa mantenere. Perché alla fine, il codice migliore non è quello più furbo: è quello che resta in piedi quando tu non ci sei più.