Tabs is obviously the right way :). It allows for setting 1 tab = N space. Faster natigation, better search and replace. It expresses intent much better. The issue is that lot of editors, formatters etc implement this so badly that there is little choice for everyone but to be forced to lower yourself to lowest common denominator and use spaces. That giant button taking up so much space on most keyboards largly gets unused :(.
Is there an editor that will format the same code file with different preferences? For example, I use 4 spaces instead of tabs and I don't like extra spaces around (). But my teammate might want 8 spaces or tabs, and extra spaces around ( ).
Why can't we both look at the same file based on our personal preferences and have, for example, GitHub convert it to the approved team standard on check in?
This way, maybe we can end the spaces vs tabs debate once and for all, and make everyone happier.
The premise of the question is a little flawed. Most people just enforce a specific editor configuration via either a pre-commit git script or a plugin-based solution like editorconfig.
Once the configuration is enforced, you can configure many (most?) code editors to visualize the whitespace as desired (tabwidth/tabstop tend to be the features to look for).
Respecting user preferences is, IMO, the major use-case for Tabs - they display indents at the depth of the viewer's preference, not the author's preference.
In theory, the ideal method would be tabs for indentation, but then further spaces for horizontal alignment if necessary. The tabs would specify exactly the logical indentation level, and only that. This way, people can change their tab width and the code will remain well-formatted. Indenting with tabs only will not allow for horizontal code alignment. In practice, mixing tabs and spaces (not to be confused with “mixing tabs and spaces” as in “some lines are indented with tabs, others with spaces” will never work reliably (and many editors/formatters prohibit it), so I’ll just take indentation with spaces, in any real-world scenario.
I'm a tab person myself. It's nice to be able to adjust the length of a tab, but I dislike when editors convert tabs into X number of spaces.
Going back and editing indentation levels usually then means turning the hidden symbols on to keep track of the number of spaces.
In a good editor too, you should be able to adjust the length of sections by simply adjusting tab length. Using spaces means manual refactoring should you wish to adjust the length of sections.
Tabs just keep everything consistent and easily managable while allowing text to be easily displayed to the user's liking depending on their editing environment.
The worst tabs situation I encountered was a co-worker who set his tab stop to 2 and then would tab four times per indention. He wasn't very well liked.
12 comments
[ 4.9 ms ] story [ 38.3 ms ] threadThe spacebar!? ;-)
I used to prefer tabs, now I prefer spaces. If we look at trends, I believe I'm in the (future) right.
Why can't we both look at the same file based on our personal preferences and have, for example, GitHub convert it to the approved team standard on check in?
This way, maybe we can end the spaces vs tabs debate once and for all, and make everyone happier.
orOnce the configuration is enforced, you can configure many (most?) code editors to visualize the whitespace as desired (tabwidth/tabstop tend to be the features to look for).
Going back and editing indentation levels usually then means turning the hidden symbols on to keep track of the number of spaces.
In a good editor too, you should be able to adjust the length of sections by simply adjusting tab length. Using spaces means manual refactoring should you wish to adjust the length of sections.
Tabs just keep everything consistent and easily managable while allowing text to be easily displayed to the user's liking depending on their editing environment.