[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] C programming, variable size array



On Fri, 12 Dec 2003 17:56:54 -0700, Monique Y. Herman wrote:

> On Fri, 12 Dec 2003 at 23:40 GMT, Paul Morgan penned:
> [snip]
>> 
>> In the real world:
>> 
>> Do the simplest thing that is consistent with the specification.
>> Someone, whose skill level you can't predict, is going to have to
>> maintain it after you.
> 
> Corollary: Regardless of the skill level of the person who maintains
> the code after you, they will find your implementation unsatisfactory,
> bitch about it at every opportunity, and beg repeatedly to be allowed to
> rewrite it.
>
> (I recently made this point at a code review.  Someone paused and said,
> "You know, you're right.  In 20 years of software development, I've
> never once met someone who was happy with the code they'd inherited.")

You are dead right.  I think this *all the time* (and that's over 30
years!). Actually, I said it recently.  There are a set of files from
other systems which come in flat and are converted to XML files, with a
few translations and database lookups, all of which is currently done by
Java processes on a separate server. My view is that this Java process is
bloated, obfuscated and completely unnecessary, as I could do the same
thing in Perl and make the code much simpler, cleaner and *much* more
easily maintainable.  I am going to get my way on this one.
> 
>> This takes quite a bit of discipline.  The temptation is always to
>> write something cool and clever.  A lot of development (and support)
>> time and money gets wasted that way.
> 
> Someone famous has a quote about how it's always harder to debug than it
> is to write code.  Therefore, if you use the full extent of your
> cleverness in writing the code, you will never be able to debug it.
> 

I agree with that.  Also, I have written "clever" stuff that I have had
difficulty understanding when I've gone back to it later, even though I
make myself comment my code liberally.

Sometimes unusual stuff works out well, though.  More than a decade back,
I implemented a doubly-linked list in Unisys COBOL (!) for a ring-polling
process.  I did hide the housekeeping in separate sections, so all one had
to do was "perform 9100-insert-element", "9110-delete-element",
"9120-next-element", and so on.  The likelihood of anyone needing to
change the housekeeping code was remote, and the main program was simpler
than it might have been otherwise.  But the real reason I *started*
writing it that way was because I thought that it would be fun, cool and
clever to implement a doubly-linked list using COBOL arrays :)

A personal observation: part of the problem with bugs in the first place
is the thoroughness and methodology of testing, which often does not seem
to be as good as it once was.  I'll stay off the soapbox here except to
say that, if you run a test and you have not documented *in advance* the
expected result, then you are *not* testing: you're experimenting. :)

BTW, the debian community deserves a lot of credit for their QA work. 
Doing QA sucks for the most part, and most folks do their level best to
avoid being part of it.  And yet debian, this cloud of volunteers from all
over the world, willingly giving their time with no compensation, produces
"stable" releases which compare very, very favorably with software
releases of similar complexity from commercial enterprises. I'd hire every
one of them if I were building a QA team :)

Sorry, just realized that I've been talking about myself too much, but now
I've written it, I'll post it anyway.  If I've irritated anyone, my
apologies.

-- 
....................paul

"Do the little things" ("Gwnewch y pethau bychain")

St. David (Dewi Sant) of Wales, last sermon, Sunday 27th February 589




Reply to: