A tabstop can be set to 1, 2, 4, 8 or 100 characters. Spaces cannot. If you set every tab to 1 character, you still see the intended indentation of the author.
So why as a community or (dare I say Planet?) Do we use spaces? Or even the worst of all defaults: tabs + spaces at the same time
If setting your tabstop was EASY and TRIVIAL in emacs or vi then I suspect the world would be moving towards tabs and away from spaces. I do not see any advantages of spaces over tabs, instead I see a LOT of advantages of Tabs over spaces, and if tabs became the standard, I suspect the options would become even better.
The ONLY time I could advocate spaces and tabs together would be something like the following:
if(somecondition &&
some_other_condition &&
a_third_condition){Ironically, I couldn't paste in tab characters into the text field for the above effect.
I will now put on my flame proof suit and wait near the garden hose.
If anyone is wondering I use emacs which by default uses tabs+spaces which is the worst of both worlds
Personally I used to use initial tabs for indenting; however over the past few years I've switched to spaces since it seems all the open source projects I work on have already chosen that standard. Even new projects I start I use spaces now since NOT using them seems to hurt contributions (people get annoyed).
I just assumed I was the only one... Is this a case of the tail wagging the dog?
The argument goes like this.
1. Tabs are indistinguishable from spaces
2. Tabs are better than spaces
3. Tabs are not supported by 100% of software properly.
Therefore...
4. Some percentage of contributors will accidentally use spaces instead of tabs.
5. When they do, they won't realise they have done it.
6. This will break indenting for tab users anyway, even worse then just having a wrong tab width.
And since...
7. People will broken tab logic are technologically incapable of fixing their problem.
Thus...
8. Any compromise on tabs versus space inevitably leads to the more-advanced tab users capitulating to the inept space people and switching to spaces for the sake of the children.
Where ... means tab:
if(
... somecondition
... && some_other_condition
... && a_third_condition
){
...
}
you can now easily comment out some_other_condition and/or a_third_condition without having to change positions of parentheses or braces.
Never mix spaces and tabs for indentation. Sure, use tabs for indentation and spaces for alignment but never tabs for both.
IMO :)
Not having to have this debate over and over again is why I wrote Text::FindIndent. It'll tell you the indentation style of a document, provided the document has more than just a handful of lines. You can feed that to your editor with some script/hook that is probably implementable everywhere.
Setting tabstop in vim or emacs is fairly easy.
Setting tabstop in xterm, less, mutt, firefox, Claws-Mail, thunderbird, WinDiff, and the thousands upon thousands of other applications your program source might end up on, is not easy.
Tabs are a terminal control sequence. They control a terminal. They are not normal text formatting. If you're going to accept them based on the principle that "if I cat a file to the terminal it looks the same", then why not allow
i (cond)\e[7Gf
to mean
if(cond)
Furthermore, try 'diff'ing a file which uses mixed tabs/spaces as indentation. Those leading "+ " "- " or " " markers throw the indentation completely off. They'll shift space-based lines forward 2 columns, without disturbing tab-based ones.
LeoNerd, I agree that it can be a pain to change *everything* I guess I was a little utopian when I wrote this entry. I also was operating on the principle that I don't use cat or xterm or my mail program to *edit* code. A mail program shouldn't have more than a few example lines in the body, the rest goes in an attachment. Any Tabs-to-spaces converter (or perl one liner) will take care of posting to Firefox etc.
However, to solve the 'diff' problems, I *ALWAYS* use -b, and if available I also use -B. The first ignores differences in horizontal whitespace, and the second ignores differences in vertical whitespace.
I guess I see a difference between display and editing. If you are editing then tabs are what you want, if you are displaying, then you will want to convert to spaces.
I spend an inordinate amount of time *reading* code using (at the moment -- in order of frequency) Chrome, TextMate, Less/More/Cat, Vi[m]. I probably spend twice as much time reading code as I do writing it.
Now of these Chrome and TextMate exist on my machine. I know how to set tabstops in Textmate, I have no clue in Chrome, and a quick glance through preferences just now didn't show me anything obvious. Less/More/Cat and Vim all exist on one of a dozen boxes I may or may not use a personal account on (and thus the ability to set my own preferences without colliding with others).
I agree in a perfect world tabs > spaces. My own world isn't perfect, let alone the world of those around me.
Diff has more subtle problems than just this though.
Imagine three lines of text, all indented by 8 spaces. Change the middle line. Diff now prepends " ", "+ " or "- " on its lines of output. 8 spaces are printed, the real starts of the lines now come in column 10, everything lines up, all is happy.
Now imagine three lines indented by a single tab. The \t is now issued on all four output lines, when the cursor is in column 3. The text following the tab now lines up nicely on column 8. This is fine, if slightly odd.
Now instead, lets mix up those lines; lets have content with a random mixture of tabs and spaces. Every line that was indented by spaces now starts in column 10, every line that was indented with tabs now starts in column 8. Output, even for lines that were not modified, is now all messed up; lines that should indent identically now do not.
Diff has more subtle problems than just this though.
Imagine three lines of text, all indented by 8 spaces. Change the middle line. Diff now prepends " ", "+ " or "- " on its lines of output. 8 spaces are printed, the real starts of the lines now come in column 10, everything lines up, all is happy.
Now imagine three lines indented by a single tab. The \t is now issued on all four output lines, when the cursor is in column 3. The text following the tab now lines up nicely on column 8. This is fine, if slightly odd.
Now instead, lets mix up those lines; lets have content with a random mixture of tabs and spaces. Every line that was indented by spaces now starts in column 10, every line that was indented with tabs now starts in column 8. Output, even for lines that were not modified, is now all messed up; lines that should indent identically now do not.
The first two scenerios that you describe are fine. The third violates the coding standard you have established ( you DID set you up right)? :)
The mixture of tabs and spaces would be for _aligning_ the following:
Any tabs which I have omitted would come at the beginning of these line.
diff would have second behavior you described as "fine, if slightly odd"
In otherwords You could find all your indenting with the following:
$_ =~ /^(\t+)/;
I agree that your third scenerio is completely unacceptable, and this is not what I meant, but frequently happens when you get people who mix the styles.
When ever this discussion pops up, I refer to reading http://www.jwz.org/doc/tabs-vs-spaces.html once upon a time, and just thinking "sod it, I'll use spaces and not spend any brain cycles on remembering all the arguments pro et con".
:-)