[Swan-dev] *cmp is a little harder to read

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

| notably neither of the confusing forms (!...cmp(a, b)) and (...cmp(a, b))
| are used.

It is all well and good to say this but it is surprising how hard it
is to maintain its truth.  I've had to whack at this several times in
the case of strcmp.  Some of the cases were actual bugs but most were
just hard to read.

The problem is a lot less severe with time because equality isn't
nearly as dominant.

| using dataless, I suspect the equivalent is:
| 
|     !dataless(c->dpd_delay, min_liveness) ? ...
| 
| but that involves actually thinking; or we go down the path of adding
| deltatime_ge() et.al.

You say "involves actually thinking" as if to mock your point.  But I
in fact think your argument should not be mocked.  Any micro-thinking
makes macro-thinking harder.  (This may be confusing: I'm supporting
Andrew's point and he's mocking it.)

My argument is more along the lines:  "deltaless(..)" is one chunk to
understand and "deltatime_cmp(...) < 0" is two or three.  I guess that
I think that 0 isn't a whole chunk but it isn't nothing (well it is
nothing numerically, but it is something cognitively).

| > It is true that *cmp is a more general primative.  But it is also
| > harder to read code using it.
| >
| > So: it is fine to add deltatime_cmp but I disagree with this comment:
| > +bool deltaless(deltatime_t a, deltatime_t b); /* obsolete; use deltatime_cmp() */
| >
| > Uses of deltaless seem clearer to me than their replacement.
| >
| 
| which I keep reading as 'data-less'  :-(

You seem to type it that way too: see above.

Would renaming it "delta_less" help?  Does that make it two chunks
cognitively?  deltatimeless is pretty undigestible.  "before" is a
really nice name but it doesn't flag what kind of time is being
considered.  Maybe "sooner" is better considering that deltatimes are
(I think) normally in the future).  Naming is important and tricky.

My suggestion: keep deltaless (however spelled (but not dataless)).
Rewrite individual calls if and only if it improves readability.  New
calls should use the most readable.  See where we get after a suitable
period.