4 ms·
This is obviously personal preference and opinion and all of that, but that's the whole point of discussion, so: if (something) { something(); } e
by natesm 15y ago
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).
I might be crazy though, because I write
int* foo
instead of
int *foo
And no one does that. Pointers are a type!
- beagle3 15y agoYou 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".
- drv 15y agoBut then you write int* foo, bar; and the troubles begin...
- natesm 15y agoAh, 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.
- sp332 15y agoBut 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.
- sp332 15y agoYes, this has bitten me recently and it's almost enough to make me type it the other way. Almost...
- kellishaver 15y agoConversely, 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. :)
- dustingetz 15y agosubjective. control flow complexity is equivalent. stop talking about it.
- sophacles 15y agoI 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.
- natesm 15y agoI 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.
- Jach 15y agoI follow Python's example for this. if (...) { ... } else if (...) { ... } corresponds to if ... : ... else if ... : ... not if ... : ... else if ... : ...
- Splines 15y agoI always write "int* foo", so you're not alone. I also prefer { else } too.