It makes no odds really. Both have slight advantages over the other but I find that if I use tabs, it only takes 1 space to mess everything up, and cause what looks fine in your editor to look like garbled crap in someone else's. Also, to pass functions with arguments split over many lines, if you use tabs then you need to tab into your main block and then use spaces to line up your arguments. This isn't fun and generally gets done wrong. This is why I play safe and stick to spaces.

Above all though, BE F*CKING CONSISTENT!

EDIT:

IMHO tabs are more correct because the length of a tab is non defined.

That's a problem. How can something that can look different on everyone's computer be a good standard for consistent presentation?

crazyjimbo wrote:That's a problem. How can something that can look different on everyone's computer be a good standard for consistent presentation?

For the same reason that it doesn't matter two hoots what font someone chooses for their editor.

Properly used, tabs are better because it allows people to choose the level of indent they want. However, they are somewhat hard to properly use, and it's hard to verify that a use is correct in a way that you can continually glance. (Coloring tabs or something like that doesn't count; too visually busy and ugly when you're trying to work on stuff.)

The fact we need to do this stems from tabs not being consistent across environments and this is thus a problem. It relies far too much on us humans being good at indenting. Considering we can't even see what we are doing/have done, this is too much to ask.

On a related note, I hope everyone agrees that tabs should be 4 spaces

crazyjimbo wrote:My main gripe with their inconsistency is the point I mentioned above in that you need to switch between tabs and spaces to get consistent indenting of multiline methods. E.g.

...

The fact we need to do this stems from tabs not being consistent across environments and this is thus a problem. It relies far too much on us humans being good at indenting. Considering we can't even see what we are doing/have done, this is too much to ask.

Yes, I agree. That's why it's hard.

On a related note, I hope everyone agrees that tabs should be 4 spaces

Unfortunately, not everyone does. There's some people in the one-true-style thread I think who think it should be a heretical 2 spaces.

I like a compromoise. My IDE (VS2005) inserts spaces when I press [tab], and also when backspacing whitespace it deletes spaces as if they were tabs. So I have all the convenience of tabs, and all the benefits of spaces.

Sc4Freak wrote:I like a compromoise. My IDE (VS2005) inserts spaces when I press [tab], and also when backspacing whitespace it deletes spaces as if they were tabs. So I have all the convenience of tabs, and all the benefits of spaces.

Arg, no, that's the worst of both worlds. You get the fiddlyness of tabs on your login, and the lack of control on other environments.

I go with amnesiasoft. I find it so much easier to just mix the two - if someone else really, really wants to read my code, it's usually well commented. I'm generallyonly use one editor per project, so no layout problems when I want to change something.

Vim documentation recommends always letting vim show the tab as (up to) eight spaces as thats the standard others will use (set tabstop=8). Then it will look the same everywhere.

Then you can use shiftwidth and softtabstop settings to control the amount of "visible whitespace" the tab, indent, unindent and backspace key will insert/remove. Soft tabs are composed of hard tabs and spaces.

So if you do it like this, you can indent as many whitespaces as you like (e.g. 4) and the only difference is whether you save seven bytes each time you see eight spaces worth of white space.

I find tabs or spaces fine, though I prefer to edit any release code to replace tabs with spaces so that it looks the same to everyone else (and honestly, if you're editing code with a box that doesn't have regex to do the reverse, what the fuck development environment are you running there?)

What I find insane is the eight spaces per tab, it's creates really awful spread-eagle code that rapidly becomes wider than my widescreen monitor. Combine eight spaces per tab with the 100-odd nonstandard characters that different projects will decide is the end of a line arbitrarily, and pretty soon you get unreadable code. Combine that with all a manner of personal preferences for different type and variable naming, and you get insanity.

Uniformity here, that's all I ask for. If everything just looks uniform I'll be happy. I don't care if it's tabs only (don't align shit if you do this though,) spaces, tabs and spaces, or whatever whitespace character you want, as long as I can change how it looks on my box. Most of the time a few regex find&replace ops will give me something I'll be ok using.

In which case, I'll fix it. I'm more concerned about consistency than occasional errors. Obviously tabs for indent, spaces for alignment is best. If I need to, I'll change it by hand, but be consistent. I don't want every file I open to require different changes.

Tabs to bring you up to the current level of indentation, that way anyone can set tabs to as many characters as they prefer, and spaces to line up two lines of code. And -do not- line up code between different levels of indentation.

crazyjimbo wrote:On a related note, I hope everyone agrees that tabs should be 4 spaces

Dingbats wrote:I'm currently using four space (as in space) indents when writing Python, but after reading this I'll likely use tabs in the future. Oh, and 80 chars width.

I have my editor set up so that hitting tab gives me fours spaces. That way I can indent my code and be sure that it won't fuck up when I open it in any other editor. Or, god forbid, if I ever subject someone else to the horror that is my code.

(79 char width though, some editors wrap the 80th character to a new line).

Dongorath wrote:(and don't like having to press backspace 4 times to go back down 1 tab).

Lol @ ur editor

In vim you increase/decrease indenting in steps of your own choosing (e.g. 4). It doesn't matter where on the line the cursor is, you just press << or >>. Or, if you want the current code block indented: >iB (means "indent inner block"). Or you can just select a number of lines and then < and > them.

For documents, tabs for obvious reasons. Documents don't use monospaced fonts, and indentation is the purpose there.

For code, always spaces. Tabs irritate the hell out of me in code. Making readable code means aligning things in a certain way, and tabs = inconsistent alignment, particularly since code should be in monospaced font anyway.

Kizyr wrote:For code, always spaces. Tabs irritate the hell out of me in code. Making readable code means aligning things in a certain way, and tabs = inconsistent alignment, particularly since code should be in monospaced font anyway.

Then you obviously don't know how to use tabs. Tabs are made for indenting because they can be set to whatever size the reader wants. Spaces are use for alignment for the EXACT SAME REASON you use tabs for indenting. Mix them together for ultimate profit!

120 chars per line because I use wide screens on a graphical interface (fill nicely on a 17" monitor, a little bit more than half the screen on a wide 24" screen).

And I agree that people that aren't consistent must spend an eternity burning in hell (or whatever equivalent in the religion of your choice).

And above all, I can't stand trailing white characters... But that's just me...

HERETIC!

There's a problem with your definition of alignment. You aren't aligning anything except by coincidence ("if (" is four characters, but "while (" is seven.) If you were aligning text, you would end up with horrible, horrible looking code to other people whose tabs are set differently.

zenten wrote:Tabs align that just fine. In fact, that's the whole point of tabs, otherwise you just have a macro for a set number of spaces, which is much less useful.

No they don't. Did you read the post Anpheus just posted, like 30 minutes ago, in this very thread?

If you are using tabs for alignment, things will align at exactly one tab setting, and this setting differs between control constructs and what you are trying to align. "Coincidentally", that setting is exactly the number of spaces that should have been inserted instead of a tab.

zenten wrote:Tabs align that just fine. In fact, that's the whole point of tabs, otherwise you just have a macro for a set number of spaces, which is much less useful.

No they don't. Did you read the post Anpheus just posted, like 30 minutes ago, in this very thread?

If you are using tabs for alignment, things will align at exactly one tab setting, and this setting differs between control constructs and what you are trying to align. "Coincidentally", that setting is exactly the number of spaces that should have been inserted instead of a tab.

If you use an eight space tab, your code will fuck up anything at or longer than eight characters. That's fourteen different keywords. At a four space tab, you'd fuck up forty-nine different keywords. At a three space tab, all but two.

Mmm, this should have been a poll. Still, I'm glad to see that most of you agree with me, and are thus smart. Tabs for indentation, spaces for further alignment, if you must.

I think one's opinion on this can tell you how pedantic a person is. The key advantage of tabs is semantic clarity: indenting and aligning convey different information, so it makes sense to use a different symbol. Otherwise, what's '\t' even for? The disadvantage is that it falls apart if people don't use it conscientiously. Now, as a pedant, I think the latter is irrelevant - people should use it conscientiously, and if they don't, let them suffer.

Compilers demand everything be perfect. You can react in two ways: either you get pissed off about it, and just keep compiling your imperfect code over and over until it works, or you accept it, and try to be disciplined. People who are willing to accept the discipline necessary to indent properly with tabs, even though it won't actually break anything if the code is ugly, are more likely to take the second approach to the strict requirements of programming, and thus are more likely to be better coders. (Correlation does not imply causation.)

The problem in having your editor showing tabs as 4 spaces is that it won't look the same in another guys editor!

I vote this as a feature, not bug.

And this is important if you're concerned about your code maxing at 80 cols...

Nah, not really. Just redefine "lines should be less than 80 characters" as "lines should be less than 80 characters with a 4-character tab stop."

If someone using an 8-character stop has to deal with lines longer than 80 characters, then too bad; he can just set it to 4-character stops, and you're almost no worse off than if you had used spaces in the first place. (In fact, if this person is editing the code, he'd probably need to change settings anyway if you used spaces, lest he start inserting 8 of them where there should only be 4.) At least with tabs you've given him a choice of (1) not worrying about the 80-col limit, (2) saying that his preference for 8-space tabs overrides his preferences for 80-col limits and leaving the settings the same, and (3) saying his preference for 80-col limits overrides his preferences for 8-space tabs and changing to shorter tabs.

There's a problem with your definition of alignment. You aren't aligning anything except by coincidence ("if (" is four characters, but "while (" is seven.) If you were aligning text, you would end up with horrible, horrible looking code to other people whose tabs are set differently.

Ok, bad exemple for the if and the four spaces tab, but that's why I said "no alignment". In my exemple, the second argument of my function is in no way aligned to the first one. That's why I said no alignment, just one more tab. Two if you really want to distinguish it from the subsequent indented block/line of code...

I'm at uni, so it is just myself that works on my code. Also, my TA uses the same IDE I do (VS 2005 with (mostly) default settings) so I need not worry about inconsistencies between editors. As long as I am consistent in my code (which I am), then I am happy, and so is everyone else. On a side note, my CS 115 prof. uses spaces to pad when she forgets a tab (or rather, destroys one that VS made), which annoys the hell out of me, just like Allman indentation, but that's for that other thread.