A design problem I met again and again.

[Steven D'Aprano]

On Thu, 02 Apr 2009 22:18:02 -0700, Emile van Sebille wrote:

> Steven D'Aprano wrote:
>> On Thu, 02 Apr 2009 16:51:24 -0700, Emile van Sebille wrote:
> <snip>
>>> I refactor constantly during development to avoid code reuse through
>>> cut-n-paste, but once I've got it going, whether it's 1000 or 6000
>>> lines, it doesn't matter as long as it works.
>> 
>> If you've been refactoring during development, and gotten to the point
>> where it is working,
> 
> yes, but
> 
>> clear and maintainable,
> 
> not necessarily

If it's not clear and maintainable, then there *is* refactoring left to 
do. Whether you (generic you) choose to do so or not is a separate issue.



>> then there's very little refactoring left to do.
> 
> Again, not necessarily.  I often find it easier to refactor old code
> when I'm maintaining it to better understand how to best implement the
> change I'm incorporating at the moment.  The refactoring certainly may
> have been done when the code was originally written, but at that time
> refactoring would have only served to pretty it up as it already worked.
> 
>> I don't think anyone suggests that you refactor code that doesn't need
>> refactoring.
> 
> That's exactly what I read the OP as wanting to do. That's why I was
> asking why.  So, I think the question becomes, when does code need
> refactoring?

(1) When the code isn't clear and maintainable.

(2) When you need to add or subtract functionality which would leave the 
code unclear or unmaintainable.

(3) When refactoring would make the code faster, more efficient, or 
otherwise better in some way.

(4) When you're changing the API.



-- 
Steven