Nathan Hurst wrote:
Jonathan Phillips wrote:
I say we lock-in our coding style standards over the next day or so. We have much to clean-up b4 a release date and some tasks are waiting for admin. decisions.
TABS
I say we lock-in at 4 spaces is a tab, and correct that in the files. GOOD?
What's wrong with 'a tab is a tab'? Then everyone can pick the size they like. (I currently prefer 8, but I'm liable to change :)
Because then when you add any extra spaces, like for lining up params, comments, etc. they don't work anymore.
I'll have to see if there's anything in Code Complete, but I've read things in the past that explained how tabs don't really gain anything, and that if a person wants to work at a different tab setting, then they can reformat, edit, reformat back, then checkin. (Then again, if they are working at 8 spaces or more, they are hitting actual bad formatting)
Most of the 'reasonable' projects I've worked with have settled on 'no tabs', and were the better for it. (Which is also why my emacs has a show-whitespace.el loaded). And we've hit actual problems in the real world that were cited in arguments presented in favor of spaces over tabs.
It's also a simplification, and I like simple. Fewer things break.
http://www.jwz.org/doc/tabs-vs-spaces.html
http://www.python.org/peps/pep-0008.html (See "Tabs or Spaces?")
http://paul.oniony.com/sections/information/tabsversusspaces.html
About the more detailed 'pro-tab' pages I could find was here: http://www.movement.uklinux.net/docs/whytabs/
However, it seems more full of personal 'gut reaction' than any empirical information. He makes no mentions of any studies like the objective ones done on code readability, and believes that 8 space tabs are the best indention (shown to be wrong).
He sets up a counter to the tabs+spaces formatting problem with non representative example, then says "Show me the editor that this can look wrong on." Well, that one specific case won't look wrong, but most the other types of cases will. And despite the author's claim, the other ways are automatically handled by Emacs, VIM, etc., not error-prone programmer kludges as he implies.
His arugument at that point is also an invalid emotional one. Paraphrased he says "here simple code that doesn't break" (non-representative sample); "but that example was from a sloppy, sucky project" and concludes "you're not involved in sloppy, sucky projects, are you?"
Appeal to fear, appeal to riducule, ad hominem, etc. More fallacy than substance. He also concludes with "Think about the relative costs and benefits. The costs are minimal; the benefits are great. " Of course, by the time he makes this claim, my critical eye has yet to see him back it up without resorting to common fallacies.
(Sorry I took so long on that, but that page at first sounded fairly reasonable. It took me a little re-reading to see all the problems, so I'd thought I'd point the need to look for them so we don't fall into them oursevles)
Oh, and for the record, I used to be a "tabs" person myself, but changed over time as I ran into problems with it (especially as I was platform hopping and environment hopping a lot). Then after the fact I found more details explaining why I hit those problems, and why that and also the indention I prefer (4 chars) is more optimal.
Anyway, I believe there are pros and cons with either approach. I see that more of the edge cases weigh in favor of tabs over spaces, but I think that they are small enough factors that a strong preference for the things that tabs give over a preference for the things that spaces give can tip the ballance. Just that we should be aware of the different issues, then make a decision.