[bind10-dev] [refactor] ChangeLog category?

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Fri Jun 18 18:46:31 UTC 2010

At Fri, 18 Jun 2010 16:43:09 +0000,
Evan Hunt <each at isc.org> wrote:
> > I agree this is an issue. 
> > 
> > "refactor" seems to make more sense to me, as we may have code that has
> > no real problems, but needs to be changed for some reason.
> > 
> > I just hope we don't end up overusing "refactor" too. ;)
> I think it makes sense to add a [refactor] category that's
> distinct from [cleanup].  But the change under discussion doesn't
> seem to me to be a refactoring.
> I guess it's a matter of personal definition.  To me, "refactoring" implies
> that the code has been changed in some structural sense (optimized, split
> into smaller units of code, etc)--altering its internals while retaining
> its black-box behavior.  "Cleanup" implies that the code is essentially the
> same but looks better:  Improved comments, clearer variable names, style
> fixes, etc.

I admit different people could have different definitions of

But at the same time, I believe the broader sense of definition is
more common.

Martin Fowler gives a quite generic definition of "refactoring" in his
  a change made to the internal structure of software to make it
  easier to understand and cheaper to modify without changing its
  observable behavior.

He also talks about renaming things in a sample refactoring process
"Never be afraid to change the names of things to improve clarity".
And he mentions code readability, too: "Refactoring helps you to make
your code more readable." (admittedly, though, this is an effect of
refactoring, rather than a definition).

wikipedia's definition seems to be aligned with these views:

Its list of refactoring techniques includes method/variable renaming:
"Rename Method or Rename Field – changing the name into a new one that
better reveals its purpose".

> (Not that it matters that much what it gets called in ChangeLog... but I
> figured, if we're going to add a new category, we should probably be on
> the same page about what it means.)

Agreed.  So, as I said, in my understanding refactoring includes these
- split into smaller units
- use clearer variable/method names
- unify duplicate code
- use a simpler algorithm/method that does the same job as the
  original code.

On the other hand, I'm not sure if I always call "optimization" a
refactoring.  If it improves performance substantially, I'd rather
consider it a new feature; if the "optimization" doesn't have much
performance effect but makes the code more readable and
comprehensible, I would consider the change a refactoring, but I would
probably not call it "optimization"; if the "optimization" makes the
code more complicated with a marginal gain of performance, we shouldn't
do that in the first place:-)

I'm not sure if I'd categorize "improving comments" or "style fix" as
a "refactoring".  But in many cases I suspect these are too minor that
we wouldn't bother to give a dedicated ChangeLog entry, anyway.  And,
this may lead to a conclusion that we may actually not need both
"refactor(ing)" and "cleanup".  If so, I'll be quite happy with that,
whichever category name we use.

Now, what do you think?  Does this explanation affect how you'd
categorize Change 57?  Or do you still believe it should be called
"cleanup" while we also have "refactor(ing)" for other types of

JINMEI, Tatuya

More information about the bind10-dev mailing list