Regola
Rimuovi commentato codice blocchi
Codice codice genera rumore, diventa obsoleto,
e fa parte nella versione di , non il codice sorgente.Introduzione
Il codice commentato si accumula quando gli sviluppatori non sono sicuri se in futuro avranno bisogno della vecchia logica. Qualcuno commenta una funzione “per ogni evenienza” invece di eliminarla, e questa rimane lì per sempre. Nessuno sa se quel codice funzioni ancora, perché sia stato disabilitato o se sia sicuro rimuoverlo. Il codice si riempie di fantasmi di implementazioni passate che ostacolano la comprensione di ciò che effettivamente viene eseguito in produzione.
Perché è importante
Manutenibilità del codice: il codice commentato costringe i lettori a distinguere mentalmente ciò che è attivo da ciò che è inattivo. Durante la revisione del codice, non è possibile capire se questi blocchi siano esperimenti temporanei, importanti opzioni di rollback o residui dimenticati risalenti a anni fa. Questo “rumore” rende più difficile comprendere la logica effettiva, individuare le sezioni di codice rilevanti e revisionare le modifiche in modo significativo.
Implicazioni per la sicurezza: i controlli di autenticazione, la logica di convalida o le funzionalità di sicurezza commentati rivelano che tali protezioni esistevano ma sono state deliberatamente disabilitate. Se il codice commentato contiene credenziali, chiavi API o URL interni, stai trasmettendo tali dati sensibili in chiaro. Gli aggressori che esaminano il tuo codice possono vedere esattamente quali misure di sicurezza hai preso in considerazione e poi rimosso.
Confusione nel controllo di versione: i diff di Git si riempiono di blocchi commentati che in realtà non subiscono alcuna modifica. Quando è necessario risalire a quando la logica è cambiata o capire perché una funzionalità funziona in un certo modo, le alternative commentate oscurano la cronologia reale. La ricerca nel codice restituisce risultati nel codice inattivo, facendo perdere tempo a indagare su percorsi che non vengono eseguiti.
Esempi di codice
❌ Non conforme:
async function createUser(userData) {
// const hashedPassword = await bcrypt.hash(userData.password, 10);
const user = await db.users.create({
email: userData.email,
password: userData.password,
// password: hashedPassword,
role: userData.role || 'user'
});
// await sendWelcomeEmail(user.email);
// await notifyAdmins(user);
// Old validation approach
// if (!isValidEmail(user.email)) {
// throw new Error('Invalid email');
// }
return user;
}
Perché è sbagliato: il codice relativo all'hashing delle password, che è stato commentato, rivela che le password sono memorizzate in chiaro, il che costituisce una grave vulnerabilità di sicurezza. Non è chiaro se l'email di benvenuto e la notifica all'amministratore debbano essere abilitate, e la vecchia procedura di convalida suggerisce che potrebbe mancare la convalida dell'indirizzo email.
✅ Conforme:
async function createUser(userData) {
if (!isValidEmail(userData.email)) {
throw new Error('Invalid email');
}
const hashedPassword = await bcrypt.hash(userData.password, 10);
const user = await db.users.create({
email: userData.email,
password: hashedPassword,
role: userData.role || 'user'
});
await sendWelcomeEmail(user.email);
await notifyAdmins(user);
return user;
}
Perché è importante: la funzione è chiara ed esaustiva e mostra esattamente cosa viene eseguito in produzione. La convalida dell'indirizzo e-mail viene eseguita per prima, le password vengono sottoposte a hash in modo corretto e tutte le notifiche vengono inviate senza alcuna ambiguità riguardo alle funzionalità attivate.
Conclusione
Elimina il codice invece di commentarlo. Il tuo sistema di controllo delle versioni conserva ogni riga mai scritta, accessibile tramite git log e git blame quando ne hai bisogno. Mantenere il codice commentato nel repository non fa altro che creare confusione, oscurando la logica effettiva e rendendo più difficile orientarsi nel codice.
