Should I use tabs?

When It Makes Sense

• Good fit: You are starting a new personal project with no existing style guide and your editor fully supports tab‑based indentation. In this case, tabs can reduce file size and let each developer display the indentation width they prefer.
• Good fit: Your team follows an established convention that mandates tabs, such as the Linux kernel or certain open‑source projects. Aligning with that standard avoids unnecessary reformatting and merge conflicts.

When You Should Avoid It

• Warning sign: You are contributing to a codebase that strictly uses spaces, for example most projects that adhere to PEP 8 for Python. Introducing tabs would create visual inconsistencies and could break automated formatting tools.
• Warning sign: Your build or CI pipeline includes linting rules that flag mixed indentation. Adding tabs without updating those rules adds friction and may cause builds to fail.

Pros and Cons

Pros

• Tabs occupy a single character, which can shrink file size compared with multiple spaces, especially in heavily indented files.
• Each developer can configure their editor to display a tab at their preferred width, improving personal readability without changing the source.

Cons

• Not all tools render tabs identically; some older editors or diff viewers may display inconsistent spacing, leading to confusing diffs.
• Mixing tabs and spaces accidentally can create hard‑to‑spot alignment bugs, especially in languages where whitespace is syntactically significant.

Decision Checklist

• Does the project already have a documented indentation policy, and does it specify tabs or spaces?
• Are all collaborators using editors that can reliably handle tabs without altering visual layout?
• Will adopting tabs affect any automated tooling (linters, formatters, CI scripts), and can those tools be reconfigured safely?

Alternatives to Consider

If you are unsure about committing to tabs, you might adopt a hybrid approach: configure your editor to insert spaces but keep the visual width of a tab for personal comfort. Another option is to use an automatic formatter (e.g., Prettier, Black, clang‑format) that enforces a consistent style across the team, eliminating the manual decision altogether. For legacy projects, consider a one‑time migration to a uniform style using a conversion script, then lock the style in the project’s guidelines.

Final Recommendation

Use tabs when you are launching a new, isolated project or when the existing codebase explicitly endorses them. In collaborative environments with established conventions, defer to the prevailing standard—usually spaces—to preserve consistency and avoid tooling friction. Whenever the decision could impact build integrity, team workflow, or compliance with external style guides, consult the team lead or refer to the project’s style policy before proceeding.