CVS update: gnucash/src/engine

[James LewisMoss]

>>>>> On Thu, 15 Feb 2001 15:35:46 -0600 (CST), linas@linas.org said:

 linas> It's been rumoured that James LewisMoss said:
 >>
 >> It's kewl with me if you want it changed back.

 linas> mm. I haven't studied it that much.  One quick question: after
 linas> your changes, were there more lines of code, or fewer?  My
 linas> impression is that there were more ... and creating more code
 linas> to eliminate code duplication is an especially dangerous
 linas> trap...

Dunno.  I didn't check.

 >> I was just starting to write some tests for this code;

 linas> good.  Needed. I've always wanted an automated test suit for
 linas> the engine.

 >> and was refactoring as a means to learning what it does.

 linas> Don't confuse 'refactoring' with 'changing the code for the
 linas> hell of it'.  Another one of my philosophies: 'if it aint
 linas> broke, don't fix it'.

I disagree again. :)  I'm not confusing refactoring with anything.
Refactoring is changing code without changing the way it works.  And
often enough being ok with changing code that hasn't been messed with
in a while "because it's working" means you get better code and code
that doesn't become cruft.

Of course to do this more safely you'd have to have tests to make sure
that the way the code worked didn't change.

 linas> I learned this from 1940's Hollywood movies where some
 linas> smart-aleck engineer delivered the phrase to some chump who'd
 linas> totally screwed the operation.  The subtext was 'you dope, the

The problem is software is not engineering.  We aren't building
bridges that if we tweak one small thing we get bad concrete and the
whole bridge falls down.  If we mess something up we can go right back
to the previous version with no consequences.  Not touching something
just because "it ain't broke" isn't a good reason for software.

 linas> The boulder of truth in this is particularly applicable to
 linas> software, where a little casual tweaking can have distant and
 linas> not immediately obvious reprecussions.

Which is why you make sure refactorings don't change the way the code
works to some outside user.  Which you do by testing the functions
before and after.

Jim

-- 
@James LewisMoss <dres@debian.org>      |  Blessed Be!
@    http://jimdres.home.mindspring.com |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach