Profit and Loss Statement for Closed Books

[Derek Atkins]

"Colin Scott" <gnucash at double-bars.net> writes:

>> While I appreciate your point of view, when someone is adding a 
>> feature to the main code it's a chore to go and test every report to
>> see if the new feature affected the output of the report.  The
>> feature-writer may not even *use* some of the reports, so may not
>> even know what the report output was supposed to be.
>
> I must confess to being a trifle bemused by your point, which seems to
> imply a lack of modular design (or failures in modular design) that I
> frankly find pretty hard to believe.  I would expect, for example and
> as a matter of good design, account selection to be completely
> standard, fully tested, and available as a simple plug-in function.
> If it works in one report, it should work in all of them - were it
> otherwise I should consider there to be a serious flaw in the design
> or implementation of that feature!  Similarly, I would expect basic
> data retrieval for those selected accounts also to be available as a
> standard, tested, plug-in function.

I wouldn't call it that per se.  But yes, there is a lot of duplicated
code in the various reports, as reports grew organically and in many
cases someone writing a report did a copy-paste-modify approach rather
than refactoring.

There was some refactoring done several years ago, but not all reports
were migrated to the new table APIs.  Such refactorings would
necessarily change the output of some reports, anyways.

The data retrieval API *is* consistent, and has been consistent for over
a decade.  And indeed that's the crux of the problem -- the API is "get
me a list of all splits in an account from date A to date B".
Unfortunately the reports needed to learn to change that to,
effectively, "all splits from date A to date B *except* closing splits".
Changing this at the low-level API would be wrong, because there are
other places where you really *do* want "all splits".  So you need to
change the places where you need to ignore the closing splits, which
means changing every report.  Sure, we could've added a new low-level
API, but it would *still* require going to all reports to change to the
new API, so it doesn't change the fact that you still need to touch
every report.

> I will admit that I have never worked on open-source development, but
> I cannot see how any significant project could be conceived were such
> basic concepts of modular design not incorporated at an early stage.
> And yes, of course, even good modular design isn't a magic bullet, but
> that and proper testing do make software more robust and less prone to
> regressions, and generally makes the regressions that might occur
> easier to track and fix.

Oh, there *IS* modular design.  GnuCash is VERY modular.  The "Reports"
are a module (and indeed each report is its own Scheme module).  But
just because you have modular design or modular implementation does not
mean that you don't have duplicated code.  And it also doesn't solve the
case where a new feature added to module A doesn't affect the results of
module B.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available