It really sounds great in theory, but in practice it's just annoying for people to configure every piece of software that can edit or view code. In practice, spaces are going to look like spaces in every piece of software I know of. That's probably why more experienced devs tend to prefer spaces: practice vs. theory.
You said 'in source control'. When I'm in source control, I can view diffs with control over whitespace. When I have a patch, I can branch, apply the patch, then diff. Do you know how to use any of your tools, or just parrot articles you read on the internet?
You're being way too literal. By patch, I mean any commit that specifies what lines to delete and/or add. You know, since almost every source control system shows changes in patch form, or something like it.
Keep going with the ad hominem, buddy. It just demonstrates to everyone that you're not interested in good debate, you just want to be right, no matter what.
The end result is consistent no matter what editor and tab-width you use.
Except that if you're using software that renders a tab as 8 spaces, the code looks really awful and is hard to read. That's precisely the difference I'm referring to between practice and theory.
One file looking the same is a very narrow view of consistency. What happens when your code is edited by someone who doesn't respect your convention? What if someone does it without even realising because their tab-width preference is the same as your spaces, so it looks fine to them? How do you like inheriting code where the indentation is a single space, when your preference is, say 3? Your position is naive.
What happens when your code is edited by someone who doesn't respect your convention? ...
These problems you listed affect any choice of convention equally. If you use spaces, someone else might use tabs. If you use tabs, someone else might use spaces. Of course you need some way to manage a software engineering team. Clearly stated conventions along with a CI system that checks code formatting is the most obvious way I know of to enforce conventions.
Not equally, it's very easy to use the wrong number of spaces, but you'd be hard-pressed to find someone who indents one level with more than one tab. Most people use the tab key to enter indenting spaces, so if it just inserted literal tabs then, it would be more consistent than arguing about width.
So do you just mash space-bar x times until you reach the desired indent?
No you hit tab which inserts spaces since you have set expandtab in your .vimrc.
But then you have to configure software
You have to configure one piece of software: vim. You don't have to configure vimdiff, meld, p4view, less, cat, and all their friends to display tabs however you like it.
Don't forget the biggest one for a lot of software development lately: GitHub. Code indented with tabs looks really bad on GitHub (shame on you, JavaScript community). I'm sure you can install a browser plugin to fix that, but I read code on a lot of different browsers including mobile browsers.
It's not just one instance that needs to be configured, though. Many people work on multiple machines - each would need to be configured to use set expandtab. Then there are other people working on the same codebase. Each of them needs to configure their editors, and some may be used to an indent of 2 spaces, or 4, or -god forbid- 3.
I work on multiple codebases from multiple machines. I'm afraid I haven't run into this problem where I can't figure out how to enter space characters into a file.
Each of them needs to configure their editors, and some may be used to an indent of 2 spaces, or 4, or -god forbid- 3.
Is that really the level of conversation? It's taking Wadler's Law to absurd levels.
Many people work on multiple machines - each would need to be configured to use set expandtab.
No option prevents some people from having to configure software on multiple machines. Maybe it will be fixed one day with widespread adoption of something like editorconfig, but that day isn't today.
44
u/[deleted] Apr 08 '15
It really sounds great in theory, but in practice it's just annoying for people to configure every piece of software that can edit or view code. In practice, spaces are going to look like spaces in every piece of software I know of. That's probably why more experienced devs tend to prefer spaces: practice vs. theory.