I'm new to professional software development and recently attended a training session where the instructor claimed that using four spaces is often more optimized than using tabs. One explanation was that code reviews do not always happen in an IDE. They described a workflow where changes were automatically formatted into a PDF and then reviewed on paper, which sounded extremely unusual to me. Is paper-based code review actually used anywhere, perhaps for compliance or security reasons? Also, is there a meaningful professional advantage to using spaces instead of tabs? I'd appreciate hearing about real-world experiences and what kinds of development practices I might encounter in the industry.
3 Answers
Paper-based code review is extremely uncommon in modern development. Most teams review changes digitally through an IDE or a web-based tool, where they can see diffs, leave comments, search the code, and track approvals. It might exist in a niche environment with strict compliance, security, or archival requirements, but it would be an exception rather than normal industry practice.
Even companies with outdated processes or strict security controls generally perform code reviews digitally. I’ve encountered old printed code and paper archives from before modern tooling was common, but that is very different from a current automated PDF-and-paper review pipeline. If a team truly does this today, it is probably driven by a specific regulatory or organizational requirement rather than being a standard software practice.
The four-spaces-versus-tabs argument is mostly a formatting convention, not an optimization issue. Tabs are specifically intended for indentation and can be displayed at whatever width each developer prefers. Spaces give every viewer the same visual width, which some teams prefer for consistency. The important thing is to follow the project’s formatter and use one convention consistently so files do not fill up with noisy formatting changes.
The paper workflow sounds like an old process that survived because nobody revisited it. Physical records can sometimes be required for audits, but reviewing software that way is slow and makes it much harder to understand context or test changes.