Aikido

Come rimuovere i commenti TODO e FIXME rimasti nel codice

Manutenibilità

Regola
Rimuovere residui DA FARE/DA CORREGGERE commenti
Irrisolti TODO e Da correggere commenti indicano
incompletezza lavoro che può si accumulino nel corso il tempo.
Tieni traccia problemi in tuo problema tracciatore anziché di lasciarli li nel codice.

Linguaggi supportati: 45+

Introduzione

I commenti TODO e FIXME nascono come promemoria utili, ma diventano rapidamente elementi fissi nel codice. Quella che doveva essere una nota temporanea si trasforma in un segnale di allarme che tutti ignorano. Questi commenti indicano lavoro incompiuto, decisioni rinviate o problemi noti che nessuno ha monitorato adeguatamente. Quando si rilascia codice contenente commenti TODO, si sta ammettendo che qualcosa non va, senza alcun piano per risolverlo.

Perché è importante

Manutenibilità del codice: i commenti "TODO" creano ambiguità riguardo allo stato di preparazione e alla completezza del codice. I nuovi membri del team non sanno se questi commenti indichino problemi urgenti o note risalenti a anni fa di cui nessuno si cura più. Più i "TODO" si accumulano, meno vengono presi sul serio, creando un effetto "finestre rotte" che porta all'erosione degli standard di qualità.

Monitoraggio del debito tecnico: i problemi nascosti nei commenti non vengono classificati per priorità, assegnati né monitorati. Il sistema di gestione del progetto mostra che tutto è completo, mentre il codice contiene decine di note del tipo “risolvere in seguito”. Senza un adeguato monitoraggio, i problemi importanti vengono dimenticati finché non causano problemi in produzione.

Implicazioni per la sicurezza: i commenti "TODO" a volte indicano implementazioni di sicurezza incomplete o vulnerabilità note. Un commento del tipo "TODO: aggiungere controllo di autenticazione" nel codice di produzione significa che hai rilasciato una falla di sicurezza con piena consapevolezza. Questi indicatori rendono più facile per gli aggressori che esaminano il tuo codice individuare i punti deboli.

Esempi di codice

❌ Non conforme:

async function processPayment(userId, amount) {
    // TODO: Add fraud detection before processing
    // FIXME: This doesn't handle concurrent payments

    const user = await db.users.findById(userId);

    if (user.balance < amount) {
        throw new Error('Insufficient funds');
    }

    // TODO: Add transaction logging
    user.balance -= amount;
    await user.save();

    return { success: true };
}
 

Perché è sbagliato: tre problemi critici (rilevamento delle frodi, concorrenza, registrazione degli eventi) sono stati segnalati ma non risolti, il che indica che questa funzione è stata rilasciata incompleta. Questi commenti documentano i problemi noti senza alcun sistema di tracciamento né tempistiche per la loro risoluzione.

✅ Conforme:

async function processPayment(userId, amount) {
    await fraudDetection.check(userId, amount);

    return await db.transaction(async (trx) => {
        const user = await trx.users
            .findById(userId)
            .forUpdate();

        if (user.balance < amount) {
            throw new Error('Insufficient funds');
        }

        user.balance -= amount;
        await user.save();

        await trx.auditLog.create({
            userId,
            action: 'payment',
            amount,
            timestamp: new Date()
        });

        return { success: true };
    });
}

Perché è importante: tutti i problemi segnalati in precedenza sono stati risolti. È stato implementato il sistema di rilevamento delle frodi, le transazioni del database gestiscono la concorrenza e la registrazione di audit tiene traccia di tutti i pagamenti. Il codice è completo e non contiene commenti giustificativi su ciò che manca.

Conclusione

Rimuovi i commenti TODO e FIXME prima di integrare il codice nell'ambiente di produzione. Se il lavoro è incompleto, portalo a termine oppure crea delle segnalazioni tracciabili nel tuo sistema di gestione dei progetti, assegnando loro la priorità e il responsabile adeguati. I commenti nel codice non vengono considerati nella pianificazione del progetto e fanno sembrare il tuo codice perennemente incompleto.

Domande frequenti

Hai delle domande?

E se avessi davvero bisogno di segnare qualcosa per dopo?

Crea un ticket nel tuo sistema di tracciamento (Jira, GitHub Issues, Linear) indicando il contesto, la priorità e l'assegnatario. Se necessario, inserisci il numero del ticket in un commento: // Vedi ticket n. 1234 per la rifattorizzazione prevista. In questo modo il lavoro sarà visibile al team di gestione del progetto e si garantirà che venga assegnata la giusta priorità.

E se avessi davvero bisogno di segnare qualcosa per dopo?

Crea un ticket nel tuo sistema di tracciamento (Jira, GitHub Issues, Linear) indicando il contesto, la priorità e l'assegnatario. Se necessario, inserisci il numero del ticket in un commento: // Vedi ticket n. 1234 per la rifattorizzazione prevista. In questo modo il lavoro sarà visibile al team di gestione del progetto e si garantirà che venga assegnata la giusta priorità.

Esistono casi in cui è accettabile utilizzare i commenti TODO?

Nelle richieste di pull in bozza o nei rami di funzionalità non ancora integrati, i commenti "TODO" aiutano a tenere traccia del lavoro incompleto durante lo sviluppo. Prima di effettuare l'integrazione nel ramo principale, completa il lavoro oppure converti i commenti "TODO" in issue tracciati. Non integrare mai i commenti "TODO" nei rami di produzione.

Come gestisco le attività in sospeso nel codice legacy?

Esaminali a lotti. Molti vecchi TODO sono ormai obsoleti o sono già stati risolti. Per i problemi validi, crea dei ticket e rimuovi i commenti. Stabilisci una politica secondo cui il nuovo codice non possa aggiungere nuovi TODO. Questo impedisce l'accumulo di problemi mentre ti occupi del debito tecnico esistente.

E i commenti HACK o OPTIMIZE?

Questi presentano gli stessi problemi dei commenti TODO. HACK indica codice di cui ci si vergogna, ma che è stato comunque rilasciato. OPTIMIZE suggerisce una preoccupazione prematura riguardo alle prestazioni. O si corregge il codice oppure lo si accetta così com’è, senza commenti di scusa. I requisiti effettivi in termini di prestazioni vanno documentati nei ticket, non nei commenti al codice.

Metti in sicurezza ora

Metti in sicurezza il tuo codice, il cloud e il runtime in un unico sistema centralizzato.
Trova e risolvi le vulnerabilità rapidamente e automaticamente.

Nessuna carta di credito richiesta | Risultati della scansione in 32 secondi.