in reply to Old NumberCrunching Modules

Sorry, but this:

I've had many functions run to 10 or more pages. I'll chalk that up to engineering versus computer science, but others may disagree.

touched a nerve. So:

<rant>

I used to work for a company offering streaming video to hand-held devices. I worked mostly on the codec, but at one point I was given the job of refactoring the top-level code of the video player.

This code was mostly a single function stretching over several pages, and had been written and maintained by a single programmer. Took me a while to figure out what it was doing, but I was able to re-factor it into reasonably-sized functions. And in the process I discovered redundancies which the author hadn’t noticed. (And no-one else would be likely to notice them, since no-one else could really follow his code!)

Now to the point: What has any of this to do with “engineering versus computer science”? Who would rate a civil engineer who designs a bridge to carry the needed loads but uses materials which wear out in a few months? (Except, of course, in special circumstances, such as in wartime.) Well then, why would any software engineer prefer monolithic spaghetti-code to modular code which is clear, maintainable, and extensible? I confess — I just don’t get it.

In my opinion, the whole engineering vs. computer science contest is a myth. The two sides come at problems from different angles, but as a rule they end up in the same place: namely, the realm of good craftsmanship and common sense.

</rant>

Just my 2¢.

Athanasius <°(((>< contra mundum

Replies are listed 'Best First'.
Re^2: Old NumberCrunching Modules
by davido (Cardinal) on Aug 13, 2012 at 15:58 UTC

    I can't agree more with the tirade against monolithic functions that span several pages. A few months ago I was working on refactoring some code where many functions reached or exceeded around 200 lines. And as I began refactoring it was amazing how many places I found that I could generalize what five to fifteen lines were doing in a way that could be reused across several of those functions. The end result was fewer total lines, no functions beyond a single page, and in my opinion, easier to read and maintain (which was my motivation behind refactoring it -- I needed to maintain it and found it to be unmanageable without this sort of sprucing up).

    My inspiration was derived from Schwern's Skimmable Code talk (PDF... sorry). I wanted to follow-up to your post to get that link out in the open once again; it's a great resource.


    Dave

[reply]

      But refactoring for the sake of refactoring - or just to get a shorter method/function body can easily led to just the oposite, as I have sadly seen way too often.

      A perfectly sane 400 line function/method stuffed with comment of a process that was a sequential series of logical steps that only got interrupted by serious Exceptions/dies was broken into several parts shattered across modules without proper call-checks and, worse, rewritten in an understanding that was not true, thereby killing the whole process.

      Some people say they understand code better when it is rewritten into smaller chunks. That might (very) well be true if any of those chunks is to be reused or makes a perfectly sane unit. If the code however is not (ever) to be shared or reused by other parts, refactoring just because of size most of the times leads to serious errors. At least in my experience.

      .

      Enjoy, Have FUN! H.Merijn
[reply]

In Section Seekers of Perl Wisdom