From: Jacob Fugal <lukfugl@...>
Date: 2005-12-15T03:27:56+09:00
Subject: Re: Idiom wanted: do-while

On 12/14/05, Steve Litt <slitt@earthlink.net> wrote:
> On Wednesday 14 December 2005 11:24 am, Jacob Fugal wrote:
>
> > Hence the need for continuous refactoring. If that's not taking
> > place, it management's and/or the developers' fault, not the
> > break statement's.
>
> It's definitely not the break statement's fault. It might not be the
> developer's or management's either. It might be the fault of the
> marketplace, which in turn is nobody's fault -- it is what it is.
>
> If taking the time to understand the code, in preparation for
> refactoring, will cause a loss of customers, refactoring can wait
> (and unfortunately usually waits until a clean rewrite).

That's unfortunate if you feel that you're in that position (and I can
sympathize, I've been there).

In my mind, refactoring is *part* of code maintenance. When you need
to fix a bug or add functionality, watch for opportunities to
refactor. Refactoring is part of writing the new code, not something
that's applied after the new code is added.

If you're understanding of the code insufficient to make necessary
refactorings while making the change, your understanding of the code
is insufficient to be making the change in the first place.

> That being said, I've always tried to refactor when possible. A lot
> of times management doesn't even know -- you just rewrite
> problematic parts.

Exactly.

> By the way, how do you like often maintained, never refactored code
> where they have three different variables representing essentially
> the same thing, and you need to decide which one to use and which
> one to set?

I assume that's a rhetorical question... :)

Jacob Fugal

P.S. Thanks for the discussion; I don't mean to be attacking you or
your practices, just evangelizing. :)