A lot of the weaker platforms don’t even support fixed width fonts. They support things like “Courier New” which only “appears” to be fixed width at certain point sizes.

Use the tab key all you want (I do) but please don’t use the tab character! Actually no, I don’t mind whatever you do, I can handle when something is displayed strangely in my editor so I’m not out to start a religious war or anything.

What disadvantages are there of treating three or four spaces as tabs? Most editors can be configured to (or even by default) automatically replace tabs with spaces. And if I press backspace @ a set of four spaces? The editor realises that it is indentation, and it wipes all of the spaces in one keypress.

Two lightweight editors I’m fond of, which exhibit this very useful capability, are Notepad++ and KATE.

Yes, when I’m in charge, I always say at the start “We’re using spaces for tabs, the tab width is four spaces, here is a set of instructions for the most popular free Windows and Linux editors and IDEs”.
I think that it makes sense. I like to code for the web. The web is about getting information from A to B. What if I’m at B and I want to edit the information?! By keeping an editor on my cellular phone, I can make little edits any time, any where.

(This is not advised for mental health reasons)

Now I’m considering upgrading to a phone that can run C++ apps (say a Symbian or Linux handset) which will surely alleviate some of my woes.

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}} .