in reply to Maintenance vs. Programming style

I've inherited code written by someone who wrote verbosely. I keep finding myself saying "I could make this so much smaller, so much more efficient".

I don't find that writing easy-to-read/-maintain code makes inefficient code. This reminds me of a conversation from a few years ago at PerlMonks where I kept trying to figure out why someone insisted on making code smaller. It turned out that they assumed that smaller code was more efficient. That isn't the case.

So I object, in general, to "more efficient" and especially to "much more efficient". Other than for quick hacks, I write efficient code that is "verbose".

Now, if somebody is writing for( $i= 0; $i < @list; $i++ ) { ... $list[$i] ... }, then I'd likely refactor to for my $item ( @list ) [or, if $i is actually used besides for $list[$i], then for my $i ( 0..$#list )] when the time comes. But the main reason for that is neither compactness of code nor efficiency. Looping over lists is less bug-prone than other types of looping.

Note that I'm not claiming that your inheritted code has been written efficiently. It is just that the phrasing made me suspect there might be a "verbose code is slow code" bias.

One of the best routes when refactoring code, especially if you didn't originally write it, is to first flesh out your unit test suite so you are more likely to notice if your "improvements" change the behavior of the code. Writing and running more unit tests also helps you understand the code more fully and may even find some long-standing bugs.

- tye        

Replies are listed 'Best First'.
Re^2: Maintenance vs. Programming style (efficiency)
by Limbic~Region (Chancellor) on Jan 29, 2008 at 04:20 UTC
    tye,
    This reminds me of a conversation from a few years ago at PerlMonks where I kept trying to figure out why someone insisted on making code smaller. It turned out that they assumed that smaller code was more efficient. That isn't the case.

    You mentioned that to me a little over 5 years ago when I had about 5 months of perl under my belt. In retrospect, I think my problem was two fold. The first issue I had was that I didn't take the time to understand what your code was doing so when it wasn't fast enough, I didn't understand how to adapt it. The second part is that I did know that fewer ops usually means less work which usually means faster run time. I was a bit naive about achieving the fewer ops.

    I try not to make that mistake anymore.

    Cheers - L~R

Re^2: Maintenance vs. Programming style (efficiency)
by apl (Monsignor) on Jan 30, 2008 at 13:59 UTC
    I should have been a little more explicit about what I meant by "verbose", but I was too interested in what everyone else had to say.

    Some of the code I was assigned was written by someone who didn't understand how to restrict scope in Perl, or specify global information. As a result, every subroutine had 15 parameters. To say this made understanding his code difficult is an understatement.

    Another former collegue never used subroutines. *sigh*

    I appreciate your comments on "verbose code is not slow code" and will try to keep them in mind. It is a fallacy I have fallen into.