Rule
Remove commented-out code blocks
Commented-out code creates noise, becomes outdated,
and belongs in version control history, not the codebase.Introduction
Commented-out code accumulates when developers are unsure if they'll need old logic later. Someone comments out a function "just in case" instead of deleting it, and it stays there forever. No one knows if this code still works, why it was disabled, or whether it's safe to remove. The codebase fills with ghosts of past implementations that distract from understanding what actually runs in production.
Why it matters
Code maintainability: Commented-out code forces readers to mentally filter what's real versus what's dormant. During code review, you can't tell if these blocks are temporary experiments, important rollback options, or forgotten remnants from years ago. This noise makes it harder to understand the actual logic, find relevant code sections, and review changes meaningfully.
Security implications: Commented-out authentication checks, validation logic, or security features reveal that these protections existed but were deliberately disabled. If the commented code contains credentials, API keys, or internal URLs, you're shipping that sensitive data in plain text. Attackers reviewing your codebase see exactly what security measures you considered and removed.
Version control confusion: Git diffs become cluttered with commented blocks that aren't actually changing. When you need to trace when logic changed or why a feature works a certain way, commented-out alternatives obscure the real history. Searching the codebase returns matches in dead code, wasting time investigating paths that don't execute.
Code examples
❌ Non-compliant:
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;
}
Why it's wrong: The commented-out password hashing reveals that passwords are stored in plaintext, a critical security vulnerability. No one knows if the welcome email and admin notification should be enabled, and the old validation suggests email validation might be missing.
✅ Compliant:
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;
}
Why this matters: The function is clear and complete, showing exactly what executes in production. Email validation runs first, passwords are properly hashed, and all notifications send without ambiguity about what's enabled.
Conclusion
Delete code instead of commenting it out. Your version control system preserves every line ever written, accessible through git log and git blame when you need it. Keeping commented code in the repository just creates noise that obscures the actual logic and makes your codebase harder to navigate.
.avif)
