One (your?) school says readability is promoted by having as much visible structure as possible. The other (mine!) says readability is promoted by having as much visible context at the same time, as long as the structure is apparent.
so instead of
if (test1)
{
do_something1();
}
else
{
do_something2();
}
I write
if (test1) do_something1();
else do_something2();
4 times as much context on in the same space. Similarly, where (I assume) you'd write:
if (a == 1)
{
c = "hello";
}
else if (b == 2)
{
c = "goodbye";
}
else
{
c = "...";
}
I write:
c = a==1? "hello":
b==2? "goodbye":
"...";
or even as a one liner:
c = a==1? "hello": b==2? "goodbye": "...";
Even if you are not used to this style, I don't think you can claim it is unreadable. Just different.
In that sort of situation I would definitely prefer the ternary, although nesting them sans (redundant, but explicit) parenthesis isn't something I would do. I also like the somewhat Rubyesque one liners for simplistic if/else pairs.
I just didn't want to write a bunch of nonsense code as an example.
This is obviously personal preference and opinion and all of that, but that's the whole point of discussion, so:
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).
You might have a point, but your arguments are inconsistent with each other; You say
> 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".
I feel perhaps you are missing my point -- you are talking about block separation and vertical space, I am talking about grouping of logical units.
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 use a newline and (sometimes) comments for that, so for example two unrelated if statements will have a blank line and some sort of comment between them.
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.
Ah, that's exactly the thing I try to avoid. Presumably you're going to use those variables, right? So, unless there's truly an issue (conditional assignment that is too complex for a ternary) why not declare them at the point of use? C99 lets us do that, there's no reason to keep the C89 habits.
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.
But it still looks cleaner to put your variables first and your code after. It's like in a play, you mention which characters are going to be in the scene before you get to the dialogue.
Conversely, I find the first example far easier to read. The second one is, to me, too "broken up" which completely interrupts the flow. To each their own. :)
Because in the 90s textmode screens looked like that. Except back in those days it was done to be able to fit 80 characters on a line instead of just 40.
Today it enables programmers to fit WAY more characters on a line.
