Codice pessimo in programmazione: cos’è, segnali e come scrivere più pulito

Cos’è il codice pessimo in programmazione

Il codice pessimo è una caratterizzazione soggettiva ma generalmente accettata del codice che non soddisfa gli standard minimi di qualità. Robert Martin nel suo libro Clean Code (2008) definisce il codice scadente come codice che “impedisce di capire cosa fa”. Il codice pessimo può essere sintatticamente corretto e persino funzionare, ma la sua manutenzione diventa un incubo per il team.

Il termine codice pessimo è diffuso proprio nella comunità di lingua russa. In inglese si usano termini più formali: spaghetti code, dirty code, technical debt code. Tuttavia, la carica emotiva di “codice pessimo” trasmette più accuratamente l’atteggiamento degli sviluppatori verso tale codice — un misto di irritazione, disgusto e offesa professionale.

Secondo uno studio di McKinsey (2023), le aziende con un alto livello di debito tecnico — e il codice pessimo ne è la componente principale — spendono il 20–40% di risorse in più per sviluppare nuove funzionalità. La qualità del codice influisce direttamente sulle metriche di business, e questa non è una metafora ma un fatto confermato.

Il confine tra codice pessimo e codice normale

Non esistono metriche oggettive, ma ci sono criteri pratici: se uno sviluppatore impiega più di 5 minuti per capire una funzione di 20 righe — è codice pessimo. Se la modifica di una riga rompe tre moduli non correlati — è codice pessimo. Se il codice non può essere coperto da test senza una riscrittura completa — è codice pessimo.

Principali segnali di codice pessimo

Il copia-incolla (copy-paste programming) è uno dei segnali più evidenti e facilmente rilevabili. Quando lo stesso blocco di codice si ripete in più punti con modifiche minime, non è solo codice pessimo — è una fonte di futuri bug. Correggere in un punto e dimenticare in un altro è una situazione tipica.

Nomi di variabili insignificanti sono un classico. Variabili con nomi come `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` non portano alcuna informazione sul loro scopo. Il lettore del codice deve analizzare l’intera funzione per capire cosa contiene la variabile. Robert Martin chiama questo “una bugia nel nome” — il nome promette informazioni ma non le fornisce.

Annidamento profondo — quando condizioni, cicli e gestione degli errori creano una struttura con 5+ livelli di indentazione. Tale codice è impossibile da leggere senza scorrimento orizzontale o monitoraggio mentale di tutti i livelli. Questa è una via diretta agli errori: gli operatori logici vengono facilmente confusi e le parentesi di chiusura vengono trascurate.

Segnali nascosti

Codice morto (dead code) — funzioni, variabili, classi che non vengono usate da nessuna parte. Questo aumenta il volume di codice, distrae lo sviluppatore e crea una falsa impressione delle capacità del sistema. Numeri magici — numeri senza contesto. Classi God — classi che fanno tutto contemporaneamente, violando il principio di responsabilità unica (SOLID: S).

Perché appare il codice pessimo

La mancanza di tempo è la ragione più comune. Quando le scadenze incombono, gli sviluppatori sacrificano la qualità per la velocità. Tatticamente può essere giustificato, ma strategicamente — è accumulare debito tecnico. Il problema è che il codice pessimo “temporaneo” viene raramente rivisto per essere corretto.

La mancanza di revisione del codice è la seconda ragione più importante. Quando il codice viene scritto da soli senza revisione dei colleghi, i modelli sbagliati si radicano e si moltiplicano. La revisione del codice non è solo controllo qualità ma anche trasferimento di conoscenze all’interno del team. I progetti senza revisione degenerano inevitabilmente in codice pessimo.

La bassa qualificazione dello sviluppatore o la mancanza di mentorship. Gli sviluppatori junior lasciati senza supervisione scrivono naturalmente codice pessimo — fa parte del processo di apprendimento. Il problema sorge quando questo codice arriva in produzione senza revisione e refactoring.

Fattori culturali

Nei team dove “funziona, va bene” è il motto, il codice pessimo prospera. L’assenza di standard di codifica, requisiti di test e processi di revisione crea un ambiente dove la qualità del codice non è preoccupazione di nessuno. Questi progetti diventano rapidamente “legacy” — codice che tutti temono di toccare.

Conseguenze del codice pessimo per il progetto

La principale conseguenza del codice pessimo è il rallentamento dello sviluppo. Il paradosso del codice scadente è che permette di scrivere velocemente la prima versione, ma ogni correzione successiva richiede sempre più tempo. Il grafico della velocità di sviluppo rispetto alla qualità del codice è esponenziale — dopo una certa soglia, aggiungere nuove funzionalità diventa praticamente impossibile.

Il turnover del personale è una conseguenza indiretta ma grave. Gli sviluppatori, soprattutto quelli esperti, non vogliono lavorare con codice pessimo. Secondo il Stack Overflow Developer Survey 2024, il 47% degli sviluppatori considera la qualità della base di codice uno dei fattori chiave nella scelta di un posto di lavoro. I progetti con codice scadente perdono i loro migliori dipendenti.

La sicurezza è un’altra vittima del codice pessimo. Il codice mal scritto contiene più vulnerabilità: eccezioni non gestite, injection SQL, XSS, perdite di memoria. Il codice di qualità con test unitari e revisione del codice cattura la maggior parte di questi problemi prima della produzione.

Il debito tecnico come metrica

SonarQube e strumenti simili possono stimare il debito tecnico in ore-uomo o giorni. Ad esempio, 500 avvisi di copia-incolla, 200 di numeri magici e 50 di annidamento profondo danno una stima di 30 giorni di debito tecnico. Questi numeri possono e devono essere mostrati alla direzione per giustificare il refactoring.

Come scrivere codice pulito invece di codice pessimo

Il principio DRY (Don’t Repeat Yourself) è la prima cosa da implementare. Ogni frammento di logica dovrebbe esistere in un unico punto. Invece del copia-incolla — estrai il codice ripetuto in una funzione, classe o modulo separati. Invece dei numeri magici — costanti con nome. Invece di funzioni lunghe — diverse piccole.

Il principio KISS (Keep It Simple, Stupid) protegge dalla complessità eccessiva. Se un compito può essere risolto in 10 righe — non scriverne 50. Se un ciclo è più semplice di uno stream — usa un ciclo. Se una funzione normale è più chiara di un decoratore — scrivi una funzione. La semplicità è la principale qualità del codice manutenibile.

La regola Boy Scout — “lascia il codice meglio di come l’hai trovato”. Anche i piccoli miglioramenti a ogni modifica trasformano gradualmente il codice pessimo in codice decente. Rinominare una variabile, dividere una grande funzione, aggiungere un test — qualsiasi miglioramento conta.

// codice pessimo — copia-incolla, numeri magici, nomi scadenti
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// codice pulito — nomi chiari, DRY, costanti
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

Esempi di refactoring

Consideriamo un esempio tipico in Python. La funzione elabora gli ordini ma lo fa male: 80 righe, annidamento profondo, numeri magici, duplicazione. Dopo il refactoring, il codice diventa leggibile, testabile e manutenibile.

# codice pessimo — una singola funzione fa tutto
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# codice pulito — funzioni e costanti estratte
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

La regola delle tre righe per le funzioni

Una buona funzione fa una cosa e la fa bene. Se una funzione fa tre cose diverse — dividila. Se una funzione ha più di 20 righe — probabilmente può essere divisa. Se una funzione ha più di due livelli di indentazione — necessita di refactoring.

Strumenti di revisione del codice

Gli analizzatori statici di codice sono la prima linea di difesa contro il codice pessimo. ESLint (JavaScript), Pylint (Python), SonarQube (multilingua), Checkstyle (Java) rilevano automaticamente copia-incolla, numeri magici, blocchi catch vuoti, funzioni eccessivamente lunghe e centinaia di altri antipattern.

Gli standard di codice e i formattatori sono il secondo livello di protezione. Prettier, Black, gofmt formattano automaticamente il codice, eliminando problemi di spazi, indentazione e parentesi. Uno stile coerente nel team rende il codice leggibile indipendentemente da chi lo ha scritto. Le discussioni sulla formattazione dovrebbero essere automatizzate.

La revisione del codice è il terzo e più importante livello. Nessun analizzatore può sostituire un essere umano che nota che l’architettura della soluzione è sbagliata o che lo sviluppatore ha scelto l’approccio sbagliato. Una revisione efficace richiede tempo, ma si ripaga riducendo significativamente la quantità di codice pessimo.

• ESLint — per JavaScript e TypeScript con regole di complessità, max-lines, max-nested-callbacks
• Pylint — per Python con metriche di codice e punteggio di qualità (da -10 a 10)
• SonarQube — per tracciare il debito tecnico nel tempo
• CodeClimate — per valutare l’indice di manutenibilità di ogni file
• Better Code Hub — per verificare la conformità ai 10 principi del codice pulito