[Swan-dev] avoiding code churn

D. Hugh Redelmeier hugh at mimosa.com
Wed Nov 28 22:56:27 UTC 2018


| commit 0f76a30e058b89c01417df6b937d928de0a446f6
| Author: Andrew Cagney <cagney at gnu.org>

|     Avoid immediate code churn by #defining isa_[ir]cookie.

Avoiding code churn has some disadvantages.  In general, I would avoid
avoiding it.

1) There are now two names for the same thing.  This is especially
dangerous when the thing is mutable: it's called aliasing.  It is a
serious source of confusion for programmers and compilers.  (I admit
that in this case, the compiler won't get confused because the
renaming is done by the preprocessor.)

2) readers need to know two ways to do something.  That's often worse
than one bad way.  It's certainly worse than one good way.

3) if the new form is better, why not get rid of all instances of the
old form, improving all the code.

4) if the new form has bugs, making the complete transition is more
likely to smoke them out.

5) a partial change adds to "technical debt".  We've already got
enough.

Why would partially implementing a change be optimal?

Perhaps if the new mechanism isn't yet complete so not all uses of the
old mechanism could be converted.

Perhaps if a lot of reworking of each use of the old mechanism were
required it might be worth doing a bit at a time.

If the problem is that it might interfere with other folks work that
hasn't been pushed, then I recommend not even starting the change.


More information about the Swan-dev mailing list