Invisible wrote:
> Hell yeah. Usually I write a program, eventually get it to almost-work, 
> and then realise that the way I structured it was totally stupid and 
> there's actually a far better way to do the job. Delete, start again. 
> Depending on program complexity, it can take a few iterations to get 
> this right.

Exactly. I think I did this about 5 times with LOME before I settled on 
how to implement that. (Including trying it in 3 different languages 
before I realized one with OO and some sort of automated memory 
management would be best.)

> It seems to be that, regardless of which programming language you use, 
> figuring out the best way to divide the problem into abstractions is 
> absolutely *critical* to writing clean, efficient, maintainable code. 
> And it's often not very obvious which way *is* the best until you try to 
> actually "do it".

Yep. That's where the experience comes in. And the natural ability to 
recognise the abstractions in things.

>> Indeed. Generally, I wind up fixing ugly when it gets to be more 
>> effort to work around the ugly than it does to fix the ugly.
> 
> This seems like it's only common sense.

You would be surprised. I've had people do things like pass the number 
of columns wide that the printer report should be in index zero of a 
floating point array indexed by customer age, just so they wouldn't have 
to spend 20 minutes to recompile other parts of the program when they 
changed what variables are shared between programs.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message