I think many people had been confused. When working in a team, everyone should follow the same standard, if one uses spaces, all others should use spaces, if one uses tab, all others should use tabs. This way, the appearence will not get messed up.

Things got messed up when some developers use tabs while others use spaces. This normally happens in a big development team. This is when a document indentations contain a mixture of spaces and tabs (this happens when different people edits the same document or source code). When this happens, the appearence will appear differently with different editors because the editors has different tab settings as some prefers 2 spaces for a tab and some others prefer 4 spaces for a tab, etc.

If tabs is preferred, the leader has to fucking make sure the others follow the standard.

Of course, things can be messed up if one is talking about tabs in the middle of lines for the purpose of table-based aligning, but I don’t see how initial tabs, used soley for initial indentation, can possibly “mess” anything up.

Maybe some editors that aren’t intended for writing code in the first place might mess things up (like a desktop publishing program), but why would someone be using anything other than a source code editor in the first place?

The W3C’s insistance that tabs be rendered at 8 spaces per tab is excessive and stupid, and I can’t believe that even the CSS3 proposal still refuses to provide a tab-setting property.

But, gosh, is it really a problem to write a stupid script for indent conversion, that would calm every upset programmer, who just received someone else’s source-code and swears at his indentation habits?

I tried to write such one :). (do not laugh, I’m not javascript guru at all…)

When not using the editor on cpanel, I use tab though. Although I will admit I did not even think about the fact of extra memory, I just did it because tabing is easier than spacing.

Whatever makes you happy…

Thanks.

Spaces increase file size which is what we’re consistently trying to reduce (in the web industry, at least). So, I say no no to spaces. Never used them, never will.

The only question I have is how many tabs to write in each line (in CSS, particularly). But that’s because my editor doesn’t allow changing the tab-size. At least, I don’t think it does… gotta check that when I’m back at work.

Thanks for the relevant questions you keep putting us, Rob. You rock. Period.

The correct method for making your code readable across a wide range of editors and UIs is to use the tab *key*, but tell your editor to use a certain number of spaces instead of the tab *character*.

I use UltraEdit32 for just about everything and it’s simple to tell it to never save tabs characters in a file and to convert them to ‘n’ spaces whenever it encounters them. Most editors have a similar capability.

If the tab key hadn’t evolved from typewriters and accountants tabbing to specific columns (2 spaces, then 6, then 8, etc) then we’d be ok but as it is, spaces are better.

Even so, my quick & dirty solution is to use the ConText or Zend IDE editor whenever someone has used spaces in their code. Both can convert tabs to spaces and visa versa without a hitch.

In the end, it sounds like it’s mostly about environment settings; if you can tune how spaces vs. tabs are handled, and you can agree within the team, it’s either way.

Personally, I think it’s harder/more annoying to edit a file with space indentation since it’s far harder to make sure that all spaces are consistent throughout the file.

And last, but not least, when i comes to HTML, CSS and JavaScript it will affect the file size that the end user has to download, so in those languages I’m strongly for tabs.

body { background: white; color: black;
.......font: medium sans-serif; text-align: justify; }

body { background: white; color: black;
font: medium sans-serif; text-align: justify; }

I find that technique most suitable for CSS because it’s nice and compact and allows me to see and work with so much more on one screen than other techniques, like one-property-per-line, etc.

For other code, JavaScript and other programming languages, I use an appropriate mix of tabs and spaces to work around the alignment problems that occur with different settings. In other words, tabs for indentation and spaces for alignment.

Note: Underscores represent tabs, dots represent spaces.

function.foo().{
____var a…….=.1;
____var longvar.=.2;

____if.(a.!=.b………// A multi-line comment that
____.&&.c.!=.d).{……// is aligned using spaces
________doSomething();
____}
}

Here’s the same code again using actual spaces and tabs for indentation:

function foo() {
var a = 1;
var longvar = 2;

if (a != b // A multi-line comment that
&& c != d) { // is aligned using spaces
doSomething();
}
}

As far as I’m concerned, that’s the only sensible aproach. Tabs for everything (including alignment) isn’t acceptable because it breaks in editors with different settings. Spaces for everything is acceptable on the condition that exactly 4 spaces are used for each indentation level.

If you’re not careful this could turn into obsessive behaviour {{guilty}} :).

But we never have any problems passing files back and forth, we just needed to make sure that our settings were synced.

When I open a file in my editor it changes their 4 spaces to tabs and vica-versa for them
So we don’t really have an issue with it.
I just prefer tabs as I think they are easier to work with (I don’t like having to press the backspace key more than times than I have to)

If you don’t compress your files in any way, be it by scripts (like Peter Bengtsson’s HTML/CSS compressor, for example) or by using mod/gzip (or both), please be aware that spaces make files larger (without any practical need) … Also, it’s sort of a “semi-standard” that one tab equals four spaces. I digress, better use tabs.

PS. Robert, apparently, even abbreviations without any title attribute set get styled.

In general, however, I completely agree as it gives more standard and regular spacing.