A design problem I met again and again.
Emile van Sebille
emile at fenx.com
Fri Apr 3 15:36:33 CEST 2009
Steven D'Aprano wrote:
> 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:
>>>> 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
> Whether you (generic you) choose to do so or not is a separate issue.
Also agreed - and that is really my point. Doing so feels to me like
continuing to look for a lost object once you've found it.
>> 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.
Certainly agreed on (2) and (4). (1) follows directly from (3). And (3)
only after an issue has been observed.
More information about the Python-list