Holy War Two: Tabs Vs Spaces
by Mark Storer · in Technical Issues · 05/16/2005 (3:20 pm) · 18 replies
This topic was beat to death in the private SDK forumns, but I thought I'd at least summerize here (Note: I'm biased. I'm a 'spaces' guy.)
The arguments for tabs (as I see them) boil down to a matter of convenience. It's what they're used to.
EDIT: Alternate Argument: When using a proportional font and tabs at specific distances (IE: a normal document editor instead of one for programming), the tabs make everything line up Real Purdy.
Alternate Rebuttal: For the love of all that is right and good: NEVER use proportional fonts when formatting your code. That's even worse than spaces. Once someone opens up your (formerly pretty) code, they're gazing into Formatting Hell. Weep for these poor souls.
The arguments for spaces go something like this:
1) With a Very Short learning curve, you can switch over. A few settings changes in your editor and a couple tips, and your off to the races. You still hit tab, but now get spaces in the source code. Using ctrl+arrow moves you through your indentation faster than you could if it were tabs without the ctrl.
2) Source code that's been nicely lined up in one editor tends to look... less-than-nice... in another. Most programming editors allow you to change the size of a tab, and unless you're viewing it at the same size, the code's alignment will be All Jacked Up. As torque is used across multiple platforms in a wide variety of editors, use spaces. Some editors (designed for normal-document writing) have variable-width tabs, and code to or from such an editor is going to Fair Poorly in the translation.
Switching has a tangible benefit _for_everyone_else_. Switching isn't hard. Come to the "space" side of the force. I am your father.
Any questions?
The arguments for tabs (as I see them) boil down to a matter of convenience. It's what they're used to.
EDIT: Alternate Argument: When using a proportional font and tabs at specific distances (IE: a normal document editor instead of one for programming), the tabs make everything line up Real Purdy.
Alternate Rebuttal: For the love of all that is right and good: NEVER use proportional fonts when formatting your code. That's even worse than spaces. Once someone opens up your (formerly pretty) code, they're gazing into Formatting Hell. Weep for these poor souls.
The arguments for spaces go something like this:
1) With a Very Short learning curve, you can switch over. A few settings changes in your editor and a couple tips, and your off to the races. You still hit tab, but now get spaces in the source code. Using ctrl+arrow moves you through your indentation faster than you could if it were tabs without the ctrl.
2) Source code that's been nicely lined up in one editor tends to look... less-than-nice... in another. Most programming editors allow you to change the size of a tab, and unless you're viewing it at the same size, the code's alignment will be All Jacked Up. As torque is used across multiple platforms in a wide variety of editors, use spaces. Some editors (designed for normal-document writing) have variable-width tabs, and code to or from such an editor is going to Fair Poorly in the translation.
Switching has a tangible benefit _for_everyone_else_. Switching isn't hard. Come to the "space" side of the force. I am your father.
Any questions?
About the author
#2
if whitespace mattered, the above code would execute like it was intended (if x then call both foo and bar). But in C and its many decendants, this is actually "if x call foo. Reguardless, call bar".
Whitespace can get messy when some people preffer tabs to spaces and visa versa... though I understand that PERL has simply DECREED a specific style.
People seldom indent incorrectly. They're far more likely to add or drop a {} somewhere, and Roally Screw Things Up.
05/16/2005 (3:43 pm)
True... I believe PERL has dropped braces in favor of indentation. A scary thought to some, but it seems like it would releave a great deal of pain:if (x) foo(); bar();
if whitespace mattered, the above code would execute like it was intended (if x then call both foo and bar). But in C and its many decendants, this is actually "if x call foo. Reguardless, call bar".
Whitespace can get messy when some people preffer tabs to spaces and visa versa... though I understand that PERL has simply DECREED a specific style.
People seldom indent incorrectly. They're far more likely to add or drop a {} somewhere, and Roally Screw Things Up.
#3
05/16/2005 (4:19 pm)
Lol, that rocks David.
#4
Either way is fine if it's done consistently,
and a team agrees (or has dictated) *any* formatting convention, it's great.
actually tabs will mess-up if you have formatting whitespace within a single line.
for example
may look great on your computer,
but if you've used 4-tabs to line up f, i, and c,
then on my computer, where i use 2-tabs, it's gonna look bad.
leading tabs are fine tho.
05/16/2005 (4:33 pm)
Which a DECREE is a good thing.Either way is fine if it's done consistently,
and a team agrees (or has dictated) *any* formatting convention, it's great.
actually tabs will mess-up if you have formatting whitespace within a single line.
for example
myFunc()
{
float f;
int i;
unsigned char c;
}may look great on your computer,
but if you've used 4-tabs to line up f, i, and c,
then on my computer, where i use 2-tabs, it's gonna look bad.
leading tabs are fine tho.
#5
Just about every script editor uses a different font, and few have a way to change it. As such, spaces can be DIFFERENT SIZES.
From my experience, most good script editors have code to figure out where the cursor is supposed to go when you tab. Eg, a tab is not always a blank space of set length wherever inserted. Take the following lines:
$Pref::Player::ModelDatablock = TabMaleHumanArmor;
$Pref::Player::Name = TabMan;
Alright, so lets say i wanted them to line up. I'd add lots of spaces:
$Pref::Player::Name = TabMan;
$Pref::Player::ModelDatablock = TabMaleHumanArmor;
(firstly, note that in my browser i can't even make them line up exactly)
Now say I changed the name of the second pref to something else, with a result like:
$Pref::Player::GamerHandle = TabMan;
To align the first one, it takes 15 spaces.
$Pref::Player::GamerHandle = TabMan;
$Pref::Player::ModelDatablock = TabMaleHumanArmor;
The second takes only 4. This means that whenever you change a variable name, you end up with some reaaaaly ugly code until you add lots and lots of spaces.
Using tabs, the editor would auto-align the values to the next tab column. No re-formatting nescisary to make that change.
05/16/2005 (4:54 pm)
Ahem. Must I point out the simple difference of FONTS.Just about every script editor uses a different font, and few have a way to change it. As such, spaces can be DIFFERENT SIZES.
From my experience, most good script editors have code to figure out where the cursor is supposed to go when you tab. Eg, a tab is not always a blank space of set length wherever inserted. Take the following lines:
$Pref::Player::ModelDatablock = TabMaleHumanArmor;
$Pref::Player::Name = TabMan;
Alright, so lets say i wanted them to line up. I'd add lots of spaces:
$Pref::Player::Name = TabMan;
$Pref::Player::ModelDatablock = TabMaleHumanArmor;
(firstly, note that in my browser i can't even make them line up exactly)
Now say I changed the name of the second pref to something else, with a result like:
$Pref::Player::GamerHandle = TabMan;
To align the first one, it takes 15 spaces.
$Pref::Player::GamerHandle = TabMan;
$Pref::Player::ModelDatablock = TabMaleHumanArmor;
The second takes only 4. This means that whenever you change a variable name, you end up with some reaaaaly ugly code until you add lots and lots of spaces.
Using tabs, the editor would auto-align the values to the next tab column. No re-formatting nescisary to make that change.
#6
Any script editor that uses a proportional font by default and does not include any way to change it should be avoided by those who wish to retain their sanity.
05/16/2005 (4:59 pm)
Quote:Ahem. Must I point out the simple difference of FONTS.That's one of the reason why monospaced fonts are included with most operating systems.
Just about every script editor uses a different font, and few have a way to change it. As such, spaces can be DIFFERENT SIZES.
Any script editor that uses a proportional font by default and does not include any way to change it should be avoided by those who wish to retain their sanity.
#7
05/16/2005 (5:07 pm)
I recently converted from Tabs to Spaces solely because Torque source always uses spaces. Never fight the style of the code you're working.
#8
05/16/2005 (5:15 pm)
Heh - i guess that was unspoken rule zero: use monospace fonts.for example the forum code blocks (like this) use monospace font. which is why llllllll takes up the same space as: 00000000
#9
No matter how much snot you beat out of it, it's not gonna get any deader.
05/17/2005 (5:45 am)
I declare this thread: Dead horse Number1... No matter how much snot you beat out of it, it's not gonna get any deader.
#10
05/17/2005 (6:39 am)
For (int horse=1; horse>0; horse++) {beat();}
#12
05/17/2005 (7:00 am)
I was feeling tautologically pedantic this morning.
#13
You know we could all stop beating this horse if we just made horse::beat recursive... Mind you there is something disturbing about a dead horse beating itself into infiniti.
05/17/2005 (7:13 am)
Lol... oh.You know we could all stop beating this horse if we just made horse::beat recursive... Mind you there is something disturbing about a dead horse beating itself into infiniti.
#14
05/17/2005 (7:33 am)
I suddenly had the image of one of those ING commercials like the "Shakespeare in the Park" or "A Man Getting in Touch with his Inner Child"...only with the dead horse.
#15
It's another of those "turing complete" dealies, but it shows such things as variable length instructions IIRC.
[Just by the way, "turing complete" generally means "useless"; if a language's best point is that it's turing complete, then it probably has between six and eight operators, takes forever to achieve anything, and can't be used for anything interesting]
Also, If you ever wanted proof that syntactically useful whitespace is catastrophically stupid, take a look at Makefiles. By the time anyone realised it was a bad idea to use tabs as delineators, the original make was already in sufficient use [about ten people] that the original author didn't want to break anything by changing it.
Gary (-;
05/17/2005 (12:06 pm)
Just for any of you who's interested, whitespace is actually an interesting language.It's another of those "turing complete" dealies, but it shows such things as variable length instructions IIRC.
[Just by the way, "turing complete" generally means "useless"; if a language's best point is that it's turing complete, then it probably has between six and eight operators, takes forever to achieve anything, and can't be used for anything interesting]
Also, If you ever wanted proof that syntactically useful whitespace is catastrophically stupid, take a look at Makefiles. By the time anyone realised it was a bad idea to use tabs as delineators, the original make was already in sufficient use [about ten people] that the original author didn't want to break anything by changing it.
Gary (-;
#16
I actually thought of a concrete reason for keeping tabs! In some environments, file size matters quite a bit (scripts-over-the-web type stuff, or a hard file-size limit). Having a single tab in place of multiple spaces could save you quite a few bits in the long run.
At that point though, you're probably better off investing in a code obfuscator that can rename your symbols down to 1-3 character names. Turning "CS_PDF_Util2_ClearFocus" into "t()" is going to pay off too. (and at that point you can just strip out most of your whitespace anyway)
Ah well.
05/17/2005 (2:08 pm)
To flog this particular horse one more time:I actually thought of a concrete reason for keeping tabs! In some environments, file size matters quite a bit (scripts-over-the-web type stuff, or a hard file-size limit). Having a single tab in place of multiple spaces could save you quite a few bits in the long run.
At that point though, you're probably better off investing in a code obfuscator that can rename your symbols down to 1-3 character names. Turning "CS_PDF_Util2_ClearFocus" into "t()" is going to pay off too. (and at that point you can just strip out most of your whitespace anyway)
Ah well.
#17
We'vebeat this horse to death, then beaten its dead body, picked up a shovel, beat it some more, dug a grave, beat it a little more, burried it... then dug the carcase out, beat it some more, sheared the flesh off, stomped the bones to dust, and for the hell of it beat the ashes around a bit...
05/18/2005 (12:04 pm)
Lol @David and @ChrisWe'vebeat this horse to death, then beaten its dead body, picked up a shovel, beat it some more, dug a grave, beat it a little more, burried it... then dug the carcase out, beat it some more, sheared the flesh off, stomped the bones to dust, and for the hell of it beat the ashes around a bit...
Associate David Montgomery-Blake
David MontgomeryBlake