| |||||||||||||
Omitting extra braces is a boonOmitting extra braces is a boonPosted Jun 10, 2008 21:56 UTC (Tue) by jreiser (subscriber, #11027)In reply to: C89 includes blocks you know... by ballombe Parent article: Implications of pure and constant functions C99 allows to omit the extra braces, but that's about it. Allowing the braces to be omitted is a significant advantage. It's some syntactic sugar that is really worth it. The combination of requiring braces and coding style conventions can cause swift migration towards the right margin. This impedes readability. I favor placing declarations so as to include the smallest possible span of lines; this eases maintenance by clearly delimiting dataflow. If I must surround every new group of declarations with braces, then the code is often two or three indentations farther to the right. Either that, or I "cheat" on the indentation rules, by placing the braces farther to the left so as to keep the same indentation for the statements which use the new variables.
(Log in to post comments)
Omitting extra braces is a boon Posted Jun 11, 2008 7:08 UTC (Wed) by jengelh (subscriber, #33263) [Link] Allowing mixing of declarations and code the C99/C++ way I consider a disadvantage, because you have to scan the entire function to get to know what variables it will use. And some people write horribly long functions without breaking them up asterisk comes to mind. Having the code go too far to the right is a sign that you should probably break the function (see CodingStyle).
Omitting extra braces is a boon Posted Jun 11, 2008 18:43 UTC (Wed) by bronson (subscriber, #4806) [Link] Doesn't your editor or IDE color the variable declarations?
Omitting extra braces is a boon Posted Jun 11, 2008 19:11 UTC (Wed) by jengelh (subscriber, #33263) [Link] That's not the point.
Omitting extra braces is a boon Posted Jun 12, 2008 0:08 UTC (Thu) by dododge (subscriber, #2870) [Link] If your point is that people write horrible over-long functions, no argument there. The C89 rules certainly didn't stop them doing it, though, and frankly if I'm dealing with some 1000-line monstrosity of a function I'd rather be able to put the declarations on the same screen as the code using them, so that 1) I don't have to keep skipping back and forth to remember the types, and 2) I don't have to worry about what the 200 lines of code between the start of the function and the spot I'm looking at might have done with those variables. But the main point, as already stated, is that from a practical standpoint you can't easily make your local variables const unless you either use mixed declarations or futz about with bracing and deep nesting. As someone who marks as much const as I can, and tries to limit scope as much as possible, I do make heavy use of mixed declarations and it's one of the C99 features that would be hardest to give up.
Omitting extra braces is a boon Posted Jun 12, 2008 13:41 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > you have to scan the entire function to get to know what variables it will use. I don't use any IDE other than plain Emacs. But there is a search function, so the "scan" that you mentioned is really by the editor program, not by myself. On the other hand, I don't find it overly useful to know what variables a function will use. It is much more useful to know what the function will do. Since I don't usually trust comments in code, this is a difficult task by itself, and it is much easier if there is not a dozen of variables springing up at the same point of code which are not used for a dozen of lines (and I have to repeatedly use the editor's search function to know about it, and then keep forgetting it 5 seconds after doing that). With C99/C++ style "declare variable on first use", I can tell easily which assignment is an initialization and which is a modification to previously assigned value, the latter I'll need to take much more care than the former. > Having the code go too far to the right is a sign that you should probably break the function Of course. But nothing beats a function that have just one or two levels of indentations: it doesn't overload myself mentally. Indentation is a necessary evil, it loads my mental capability, but if you have a loop body you have to somehow differentiate it from the code outside the loop, so it is still the best choice. Using braces also for just variable declaration leads to quite a few more levels than what I usually want to see in the code, especially those written by somebody else. And "break the function" is not always practicible. Yes it is usually good, and when it is good it is the best choice. But at the same time usually it is not good: at times it creates a whole brunch of functions that has little meaning by itself and has to be called from a particular context to be useful at all, and the context is in a form of very complex preconditions involving its arguments, sometimes involving additional structures to hold the results, the structures, of course, are of little meaning by themselves as well. A language feature that provides an alternative when such "golden rule" is not practicible can only be a good thing.
|
|||||||||||||