Opinions about programming styles

[superbonzo]

Generally, spaces are a better choice [...]

what I dislike of space-filled "tabs" is when the cursor gets "trapped" in the indented area and you want to move to a specified indentation level ... in the editors I've used, is a frustrating experience

[...] because they allow more customization of indent levels.

do you mean different sizes for each indentation level ? what's the benefit ?

[laserlight]

do you mean different sizes for each indentation level ? what's the benefit ?

I do not presume to know exactly what Lindley meant, but one advantage of the use of spaces for indentation is illustrated by Moschops' example in post #4:

void clicked_cb(ClutterClickAction* action,
                ClutterActor*       actor, 
                gpointer            user_data)

Spaces are likely to be used to align the second and third parameters with the first since if tabs were used, there is the risk of misalignment should the tab width be different from what is expected. If this were a member function, then the declaration would likely be indented. So, if tabs were used for indentation, then we would have one or more tabs followed by the spaces used for alignment, which is a Bad Thing since it a mixture of tabs and spaces that requires more care to get right.

[monarch_dodra]

Another advantage of spaces over tabs is portability. Some editors consider 1 tab = 2 spaces, while others consider 1 tab = 4 spaces (and some even consider 1 tab = 8 spaces).

As long as spaces and tabs are not mixed, then it *should* be fine, but they are always mixed...

The ONLY thing (I can think of) that tabs have going for them is size in terms of bytes, but in this day and age, I'd say it's largely irrelevant

[D_Drmmr]

I do not presume to know exactly what Lindley meant, but one advantage of the use of spaces for indentation is illustrated by Moschops' example in post #4:

void clicked_cb(ClutterClickAction* action,
                ClutterActor*       actor, 
                gpointer            user_data)

I find that aligning variable names like this makes the code much more difficult to read.
It's also a horrible style for writing code if the editor does not do this automatically. When you add a variable to the parameter list, you don't want to waste time having to fix the alignment of the other variable names.

[Lindley]

It's not something to be done all the time, but now and then it can help a lot.

[laserlight]

Moschops' example in post #4:

Hmm... my mistake. I see that this is actually JohnW@Wessex's example in post #3, quoted by Moschops in post #4.

I find that aligning variable names like this makes the code much more difficult to read.

I find it quite readable, though I do not do such alignment myself. What could be awkward is when there is a parameter with a short type name and another with a long type name, so there ends up with a large gap in between the type name and parameter name for the parameter with a short type name. Note that my citing of this example has to do with the alignment of the parameters themselves, in effect meaning the alignment of the type names.

It's also a horrible style for writing code if the editor does not do this automatically. When you add a variable to the parameter list, you don't want to waste time having to fix the alignment of the other variable names.

Even if an editor does not do this automatically, it may provide vertical selection that allows the alignment of all the parameters to be changed simultaneously.

[JohnW@Wessex]

When you add a variable to the parameter list, you don't want to waste time having to fix the alignment of the other variable names.

I used to use the format in conjunction with a code formatter that automatically aligned the parameters for me.

What could be awkward is when there is a parameter with a short type name and another with a long type name,

That can look a little odd, though it was not a common occurance.

[VladimirF]

I am a frequent participant in "tabs vs spaces" discussions
I am writing code for almost 30 years, in various languages, for multiple companies and as a sole developer.
Can we limit the arguments to C++ in a modern editors, for simplicity?
Here are some assumptions that I think are fair:
1. The code is written (and, particularly, formatted) for the reader, and he is likely NOT you.
Conclusion: your code should be easily adopted to the reader's taste. Hint: it is seamlessly achieved when you use TABs.
And a bit less obvious:
2. All white space at the beginning of the line is INDENTATION, the white space in a middle might be alignment.
The reasoning here is that by scanning the left edge of the code you can deduce its logical structure. That, of course, is unless you use your code as ASCII art.
Conclusion: NO alignment, at least - not at the beginning of the code line.

And here is my suggestion for the above code example (for people who like alignment):

void clicked_cb(
    ClutterClickAction* action,
    ClutterActor*       actor, 
    gpointer            user_data)

[Lindley]

1. The code is written (and, particularly, formatted) for the reader, and he is likely NOT you.
Conclusion: your code should be easily adopted to the reader's taste. Hint: it is seamlessly achieved when you use TABs.

Counterpoint: If the code is being viewed in multiple environements, for instance both emacs and Visual Studio's editor, and perhaps a version control system's built-in viewer, it is best if it looks the same everywhere. This is most easily achieved when you use SPACES.

[VladimirF]

Counterpoint: If the code is being viewed in multiple environements, for instance both emacs and Visual Studio's editor, and perhaps a version control system's built-in viewer, it is best if it looks the same everywhere.

Oh, that is a frequent, but not a very strong point at all!
Sorry, I am not familiar with emacs.
But *I* am reading the code in the version control system, and I sure want it to be formatted to *MY* liking.
SVN (Tortoise) can to it. Perforce could too. Which one can't? May be you should reconsider your choice of software?
Caveat: I do know one exception: the web browsers. They either can't, or I simply didn't find a way to specify the size of the TAB in spaces...

[monarch_dodra]

Conclusion: your code should be easily adopted to the reader's taste. Hint: it is seamlessly achieved when you use TABs.

While I'd agree, that would require an incredible amount of rigor on the part of all developers: 1 single developer who uses spaces where tabs are needed can mess up your indentation.

I am working on a project: Our team here, and another team overseas. We like 2 spaces per indentation. They like 4 spaces per indentations. tabs are the bane of our existence.

[VladimirF]

1 single developer who uses spaces where tabs are needed can mess up your indentation.

Just shoot him then
That's what Coding Standards are for!