Opinions about programming styles

Quote:

---

Originally Posted by Lindley

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 :)

Quote:

---

Originally Posted by Lindley

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

---

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

Quote:

---

Originally Posted by superbonzo

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:

Code:

---

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.

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

Quote:

---

Originally Posted by laserlight

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:

Code:

---

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.

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

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by D_Drmmr

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.

Quote:

---

Originally Posted by D_Drmmr

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.

Quote:

---

Originally Posted by D_Drmmr

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.

Quote:

---

Originally Posted by laserlight

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.

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):

Code:

---

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

---

Quote:

---

Originally Posted by VladimirF

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.

Quote:

---

Originally Posted by Lindley

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... :(

Quote:

---

Originally Posted by VladimirF

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.

Quote:

---

Originally Posted by monarch_dodra

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!