if (something) {
something();
} else {
something_else();
}
vs. if (something)
{
something();
}
else
{
something_else();
}
To me, the first one is chaotic. It's not so bad like that, but throw in a loop (as well as the external function declaration) and it's a complete mess.The second one is orderly. Block separation is very clear, and each brace is matched by an equal.
IMO, if you need to worry about how many lines of code fit on your screen, it's probably time to refactor (or upgrade from a netbook).
I might be crazy though, because I write
int* foo
instead of int *foo
And no one does that. Pointers are a type!> IMO, if you need to worry about how many lines of code fit on your screen, it's probably time to refactor (or upgrade from a netbook).
But also:
> Block separation is very clear, and each brace is matched by an equal.
Block separation is equally clear in the first example (same column means same block), and if your IDE can't show you matches if you're lost, it's time to upgrade from ed or edlin.
Also,
> I might be crazy though, because I write "int* foo" instead of "int \foo" [edit: \ should be asterisk. can't make it show one, though]
You are indeed crazy, or at least misguided and confusing. because
int* a, b;
implies a and b or both of type "int* ", but actually, a is of type "int* " and b is of type "int". The second form is visually consistent, because: int *a, b;
Says "*a" is of type "int", and also "b" is of type "int". int* foo, bar;
and the troubles begin...Meaning:
int* foo = whatever;
// do some stuff with foo, now we need bar
int* bar = whatever;
Outside of a for loop, I would never do two assignments on the same line, so it isn't an issue.If it really has to be done like that, I just suck it up in that case. C has its warts.
I completely get the reason why code blocks were first introduced in these comments, but think the "int" versus "int " discussion is offtopic.
I agree with your points for functions, (most)loops, switches, and so in, but for if/else try/catch/finally do/while an other multiblock statements, I think it helps to have some convention to group them, other than indent level. The blocks depend on each other, not just are in proximity.
I would never do:
for (a;b();a++) {
stuff();
} if (test) {
...
}
because the if and the for are not parts of the same logical chunk. Nor would I do: ...
} else {
catchall();
} if (new_test()) {
...
Again because a new if is new logical chunk.Basically, it isn't about block delineation or about vertical space, its about grouping logical units that have multiple blocks at the same nesting level.
I think it would be really interesting to see how people's code style preferences translated to how they design things (or prefer designs). I like minimalism and lots of whitespace in designs, and it definitely translates to how I best read code.
if (...) {
...
} else if (...) {
...
}
corresponds to if ... :
...
else if ... :
...
not if ... :
...
else if ... :
... {
else
}
too.