Aikido

Why you should remove commented-out code from your codebase

Readability

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.

FAQs

Got Questions?

What if I need the old implementation for rollback?

Use feature flags or version control branches, not comments. If you might revert to old logic, implement it behind a feature flag you can toggle. For permanent changes, delete the old code and rely on Git history. You can always retrieve deleted code with git log -p or git show when needed.

How do I handle experimental code during development?

Keep experiments in separate branches or feature flag them. If you're testing two approaches, create a branch for each or use a configuration flag to switch between them. Commented-out code in main branches suggests you're not sure what should be in production, which is a planning problem, not a version control problem.

What about temporarily disabling code during debugging?

That's fine for local debugging sessions, but never commit it. Use git add -p to review and exclude commented-out debug code before committing. If you need to disable code temporarily across the team, use feature flags or configuration rather than comments.

Should I remove commented explanatory notes too?

No, this rule targets commented-out code blocks, not documentation comments. Explanatory comments that describe why or how something works are valuable. The issue is blocks of commented-out executable code that may or may not be relevant anymore.

What if commented code documents old implementation approaches?

Document the approach in a comment that describes it, not by preserving dead code. Write "previously used X approach, switched to Y because Z" instead of keeping both implementations commented out. Historical context belongs in commit messages and design docs, not dormant code blocks.

Get secure now

Secure your code, cloud, and runtime in one central system.
Find and fix vulnerabilities fast automatically.

No credit card required | Scan results in 32secs.