I always enjoy spaces vs. tabs debates, people can get so wonderfully emotional about it. It’s almost like politics.

Perhaps in a next blog post you could talk about K&R vs. whitesmith vs. Allman and bracket placement for code blocks. That’s always a good debating point as well :)
(I prefer whitesmith/allman, less bugs per line :P )

Also, I think all arguments that talk about it being hard to be consistent with spaces and tabs should join the 21st century and just configure and use a code beautifier. Granted I mostly use a IDE instead of just a editor, but I’m reasonably sure there are similar tools for vim and emacs.

If you are unable to read function definitions with long parameter counts (how many of those do you have in a single file anyway..) you might want to consider seeing an optometrist.

Every single point of a space being preferable to a tab is complete and utter nonsense. If, for some reason, you’re stuck in the pre Vietnam war computing era and are unable to fit more than a couple of characters on a single line, I suggest upgrading your hard- and/or software.

Not to mention that every single decent text editor has the ability to set the displayed tab-width to whatever you please. And if you really (although I really can’t imagine why) want to align function parameters in some in(s)ane way, I suggest you try to improve your text editor of choice to do just that.

But please, don’t insert random crappy spaces just to make something “pretty”. It’s a complete waste of time and it increases source file size for no good reason at all.

[tab]

is not correct syntax :P

you should use the correct actual tab character for your indenting :D

http://nickgravgaard.com/elastictabstops/

They are a good compromise the this issue.

All good editors today know how to edit with spaces that behaves like tabs, problem SOLVED.

shift-tab it’s the right answer.

[tab]my_long_funcion (
[tab][tab][tab]item1,
[tab][tab][tab]item2,
[tab][tab][tab]item3);

or

[tab]my_long_funcion (item1,
[tab]……………..item2,
[tab]……………..item3);

reference:
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Indentation#Indentation

[tab]my_long_funcion (item1,
[tab][tab][tab]item2,
[tab][tab][tab]item3);

The advantage to this is that the parameter indent is consistent across ALL method calls, meaning that if I rename my_long_function() to some_semantically_better_name() (yay refactoring), I don’t need to reindent all of the parameters (thus minimizing diffs in the revision history).

I really don’t understand the need/desire to have all parameters “lined up” underneath the opening ‘(‘ of the function call. Indentation is certainly required, but to have a variably sized indentation, based solely on the function called, seems quite silly.

leave people using the tab length they are confortable with, and don’t force your likes to others !

Doing this indentation style manually is really not that bothersome, and actually much easier than dealing with spaces-only in a simple editor like Gedit. Yes “insert tabs as spaces” is trivial to implement, but it still requires you to hit backspace up to 8 times everytime you need to remove a single indentation, which is a huge PITA. Not to mention that it’s extremely easy to make a mistake, and I’m just tired of dealing with source code that is a huge mess of spaces thrown all over the place (yes it wouldn’t happen if everyone would use emacs or vi properly, but that’s not reality).

Even if someone gets the alignment wrong (which is easy to fix when I stumble across it), working with code that uses tabs still tends to be a lot nicer.

Once upon a time I used spaces, but then somebody convinced me that allowing people to have variable indentation through the use of tabs was better, and so I switched. Displays vary so much that it’s nice to let people tweak it to suit them.

@oliver: 80 column wide lines of code seems to me a very archaic limitation these days, since our screens can, typically, show far more than that. Okay so you don’t really want to go too high because the readability goes through the floor, but it’s not so much of a problem on a big screen if the indentation goes deep but the line itself stays fairly short. Deep indentation is or can be indicative of other problems, but trying to stick to 80 columns seems like an unnecessary handicap to me.