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?
Please take some time to look at that coding standards document and help clean it up. If we lock-in our standards for the project now, then lotsa ppl can help clean-up the code, help document it, and then we can move forward with C++'ification even more.
Jon
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 :)
njh
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.
Jon A. Cruz wrote:
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.
That's not true. If you use tabs for indenting and whitespace for alignment then it works everywhere.
Most of the 'reasonable' projects I've worked with have settled on 'no tabs', and were the better for it.
Or you bashed them into using it. :)
he doesn't really give a good reaons for not using tabs, beyond "that's what I use".
http://www.python.org/peps/pep-0008.html (See "Tabs or Spaces?")
python is special because the interpreter assumes tabes are 8 spaces (that is, it folds tabs into spaces, and of course spaces are important in python). We're talking about C++ here.
http://paul.oniony.com/sections/information/tabsversusspaces.html
I'm arguing for what he calls "Hybrid Indentation".
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).
I don't care about how long you choose your tab to be. That's why I like tabs are tabs :)
(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)
You haven't exactly enunciated the issues yourself :)
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.
I don't care if you like 4 chars, with hybrid tabs I can choose the far more reasonable 5 tabs stops.
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.
Yep, well when you've finished working it out, give me an emacs style, indent region on all the files and and we can move on to more interesting issues, like why my patch doesn't work....
njh
Nathan Hurst wrote:
Jon A. Cruz wrote:
Nathan Hurst wrote:
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.
That's not true. If you use tabs for indenting and whitespace for alignment then it works everywhere.
For some cases, yes, but for other cases no. (and when discussing this point, it's best not to use a strawman like that article did)
Here's the first function I had in code that took two params (just looking for a sample):
void ColorSelector::setColorAlpha( const SPColor& color, gfloat alpha )
Let's tabify it using 4-step tabs: void ColorSelector::setColorAlpha( const SPColor& color, --->--->--->--->--->--->--->--->...gfloat alpha )
and using 8-step tabs: void ColorSelector::setColorAlpha( const SPColor& color, ------->------->------->------->...gfloat alpha )
and finally using 5-step tabs: void ColorSelector::setColorAlpha( const SPColor& color, ---->---->---->---->---->---->---->gfloat alpha )
Hmmm... uh oh. that last one looks like trouble. But that first one had the same number of spaces left. Lets see what we get when we view using different tab settings from the 'original' tab user:
4->8 void ColorSelector::setColorAlpha( const SPColor& color, ...................................................................gfloat alpha )
8->4 void ColorSelector::setColorAlpha( const SPColor& color, ...................gfloat alpha )
4->5 void ColorSelector::setColorAlpha( const SPColor& color, ...........................................gfloat alpha )
5->4 void ColorSelector::setColorAlpha( const SPColor& color, ............................gfloat alpha )
So it looks like it's fairly simple to show things breaking down. And for the alignment of things there I didn't even pull manual tricks. That's a common way for editors to format code. Emacs and DevStudio both do it, and I believe that VIM does also.
Most of the 'reasonable' projects I've worked with have settled on 'no tabs', and were the better for it.
Or you bashed them into using it. :)
Nope. I've not been lead architect on most projects over the last several years. Two of my leads have been PhDs (just in case one was assuming I've only been working in barbiarian land). Hard to bully those guys. :-)
(Also, I'm trying to break these follow-ups down to single issue)
Nathan Hurst wrote:
Jon A. Cruz wrote:
http://paul.oniony.com/sections/information/tabsversusspaces.html
I'm arguing for what he calls "Hybrid Indentation".
Yes. That does solve many of the problems of programmers using different tab sizes. However, as was pointed out when this came up in discussions earlier, this takes major hand-tweaking and most editors aren't setup to deal with it by default.
And as noted on that page:
However, this approach requires a lot discapline and clean-up maintenance and is virtually unworkable on any sizable project. Even if you are able to explain the approach, and convince your peers of its merits, it would still be hard to gain everyone's cooperation. It will certainly be more difficult than enforcing a 'just tabs' or 'just spaces' convention.
So I think I fall in with the opinion that it does solve the alignment problems, this is 'good', however it complicates maintenance, therefore is 'Bad' (capital in this case, lowercase for 'good').
On Sat, 17 Jan 2004, 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.
Good idea.
TABS
I say we lock-in at 4 spaces is a tab, and correct that in the files. GOOD?
That sounds like a good number to me.
Please take some time to look at that coding standards document and help clean it up. If we lock-in our standards for the project now, then lotsa ppl can help clean-up the code, help document it, and then we can move forward with C++'ification even more.
Thanks, you're right this will be a good thing to get locked in right now.
Bryce
participants (4)
-
Bryce Harrington -
Jon A. Cruz -
Jonathan Phillips -
Nathan Hurst