I prefer a GNU-like style (but without extra spaces for the braces-on-their-own-line -- leave them at the same level as the parent block)
My style complaints about that code have nothing to do with tabs, though, and everything to do with naming, using a while with a non-boolean condition, and doing a PRE-INCREMENT IN THE F*CKING RETURN STATEMENT. (Oh, and spaces between the function and its parameter list. foo( bar ) ties the parameter list to the function name in a much stronger manner than foo (bar) ).
Unless x is static, "++x" is terrible. If it *is* static, "x" is a terrible name. Incrementing implies there's a reason you're assigning to x, leading to no end of reader confusion when they try to figure out why you chose not simply to add 1 to x. By application of your own dictum, this is a failure.
The while test is a common enough C idiom I'd let it slide[1], though it once again fails at clearly communicating your intent.
D'A
[1]: Here, "let is slide" means "do it that way myself".
Consider if bar is a functor, to which x is a pre-bound argument. The return result is dependent upon the order of evaluation of the terms on return line.
Is that well specified? Do you remember the order?
--
Ignoring that specific case, I'm very much of the opinions that return statements should not have ambiguous side effects. (Is x a class member or a reference parameter? If so, increment it first and then do the line. If not, just do a +1 or a x.Increment() ).
For the while statement, its simply a personal preference.
Discussion (14)
The above is GNU style which I always found to be an excellent style guide:
http://www.gnu.org/prep/standards/standards.html
Heh. No, quite right Sir! You have me!
Ha Ha Ha Ha... Anyway...
It's not my style anymore. Much to my chagrin I have switched (subconsiously) to stupid BSD style:
yuk. My style sucks.
I prefer a GNU-like style (but without extra spaces for the braces-on-their-own-line -- leave them at the same level as the parent block)
My style complaints about that code have nothing to do with tabs, though, and everything to do with naming, using a while with a non-boolean condition, and doing a PRE-INCREMENT IN THE F*CKING RETURN STATEMENT. (Oh, and spaces between the function and its parameter list. foo( bar ) ties the parameter list to the function name in a much stronger manner than foo (bar) ).
Claims inspired by this comment
There should be no space between a function name and the paren that starts the argument list.Your style is called Stroutstrup, after Bjarne.
I personally don't see anything wrong with either the pre-inc or the while test.
What do you think is wrong with them?
Unless x is static, "++x" is terrible. If it *is* static, "x" is a terrible name. Incrementing implies there's a reason you're assigning to x, leading to no end of reader confusion when they try to figure out why you chose not simply to add 1 to x. By application of your own dictum, this is a failure.
The while test is a common enough C idiom I'd let it slide[1], though it once again fails at clearly communicating your intent.
D'A
[1]: Here, "let is slide" means "do it that way myself".
Consider if bar is a functor, to which x is a pre-bound argument. The return result is dependent upon the order of evaluation of the terms on return line.
Is that well specified? Do you remember the order?
--
Ignoring that specific case, I'm very much of the opinions that return statements should not have ambiguous side effects. (Is x a class member or a reference parameter? If so, increment it first and then do the line. If not, just do a +1 or a x.Increment() ).
For the while statement, its simply a personal preference.
The functor objection is pretty.
D'A
Actually, now that I think more about it, I'm unclear what you mean by the combination of "functor" with "pre-bound argument". Explain, please?
D'A
std::tr1::bind()
You create a functor with an arbitrary number of parameters, and can specify an object, held by reference, to be the nth parameter for that functor.
Ermm... the above code is C. You don't think the GNU project would put C++ in a style guide?? Goodness, how quaint.
@nic: Its "Stroustrup", without that first "t".
@fiXedd thanks. If you could just crawl through jyte and correct all my other misspellings that would be great.
I'll get right on that :)
You can do fuctors in c, with pre-bound variables. Especially since references ( Foo &foo ) is C (as of C99).
So are namespaces
It is just easier to refer D'arch to the C++ code, than to write functors by hand.