zack> Seriously? You think that my efforts have increased the obfuscation?
No, in generally it is _fantastically_ better. But as they say, no good
deed goes unpunished. As I said this is a "nit".
zach> I hope that you can engage in a rational discussion about this
topic.
Simple. Please understand I am referring to *this* item, 99% of what you
have done is great.
duane>> bool okay = *str && !*end && ULLONG_MAX != *ul;
in that simple expression 13 things are going on.
(1) variable definition
(1) assignment
(4) variables (1 is a macro value)
(3) indirections
(1) negation
(2) logical and operators
(1) inequality test
===
total 13 things.
This does not pass the K.I.S.S. principle.
Why not not add a () around that, and do it all in the return statement
ternary operator?
====
Perhaps your approach is different then mine, I let the optimizer be
the smart one.
It is a well trained machine, it tends to make fewer mistakes then me.
My approach is:
(1) less complex if() statements, so what if they are nested some..
That is the optimizers job...
(2) simplistic early returns, or "goto bailout' statements.
The optimizer merges and makes it better.
These help reduce nesting levels.
(3) fewer steps in a mathematical expression,
With a complex expression, the debugger cannot step through the
expression.
If you cannot step through the expression with a debugger - it's
hard to test.
(4) If needed, break the expression in half.
Add a few simple temp variables to simplify the steps
The optimizer can put them back together.
(5) Extra braces{} and/or parens() - are like Rick points out
not there for functional reasons, but for clarity reasons.
yes, there are limits on both sides of the discussion, one can easily
go overboard with the above suggestions just as poorly.
In this case - this expression, this place, my reaction was WTF!
====
I've also had to fight the battle of idiotic complexity scanners, and
justifying why
metric (A) is wrong here, and correct there, while metric (B) says the
opposite.
Many times I've had a new guy (from DOD work, where they had to meet
certain complexity metrics) start work and sit and think hard about
some stupid
sequence of code - much like this example, rather then simply coding it.
Why? Because "the culture they grew up in" required that style of work.
I always liked asking a few questions of the new guy and asking if they have
ever rated the complexity of "pointer stew" -
http://blogs.sun.com/plamere/entry/pointer_stew
Complex multi-step expressions like this, remind me of Pointer Stew.
===
-Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
