No matter where you fit into any of the great developer debates (vim vs Emacs, tabs vs spaces, 80 vs 120 vs no column limit) the most critical point is consistency. Switching between tabs and spaces inside your own project would certainly prove annoying for others should you share the code even it won’t affect function. When you’re working on a team, though, or as part of a large organization; consistency has to exist not just in your project but across many.
Maybe you’re a tab person. Cool. Go nuts; at home. If your company prefers spaces the reality is that your preference doesn’t matter. Conforming to a shared norm is more important. When you have to share code with others the bottom line is that the consistency is bigger than your preference. This can even escape your own company should you end up open-sourcing your work for others to benefit from.
This is why I prefer to lean on community-driven style guides. I may not agree that Ruby should be written with an 80 character line limit but the community-driven Ruby Style Guide says otherwise and Rubocop defaults to that as well. Given that; it then makes sense that in any project that I plan on making public I should follow these norms as much as possible.
It’s hard to get consensus when opinions are strong and nobody’s preference is really wrong (unless they prefer tabs- then they’re wrong). Rather than infighting and company-specific styles that lead to Python that looks like Java and Perl that looks like, well, chaos we should be able to agree to disagree and stick to accepted solutions. I’m going to link a few below. Mostly these are the top or near-top hits on Google if you look for style guides for these languages. Google is the source of some but as the massive engineering powerhouse they are that makes sense.
Decide what to use, commit to move forward with it, and stop wasting time arguing over the right column to end the line at.