Re: Did I write a good (efficient) program?

-- 
"I used to write COBOL...now I can do anything."
"Michael Mattias" <mmattias@[EMAIL PROTECTED]
> wrote in message 
news:57qIj.23163$0o7.2366@[EMAIL PROTECTED]
> You know, I've always used three tests to decide if code is
well-written:
>
> 1. Does it work?
> 2. Is it *relatively* efficient?
> 3. Is it maintainable?
>

Yep, same priorities I have always observed also...

However, in the light of my experience over the last decade or so, I would

qualify these criteria with: "applies only to Procedural Code."

OO Code has a different set...

1.  Does it work?
2.  Is it small and complete (encapsulated)?
3.  Can I reuse and extend it easily?

Efficiency is taken care of by keeping components small, and using 
optimizing compilers.

Maintainability is not a consideration as long as the interface is simple
or 
non existent. I like to use internal properties (via GETTERs and SETTERs)
to 
modify behaviour of components, as this avoids needing parameter
interfaces, 
but it isn't a hard and fast or black and white rule, and it is certainly 
arguable... I have found it works and can completely eliminate
maintenance. 
These days I write stuff, thoroughly debug it, then forget about it. I
don't 
plan to "maintain" encapsulated functionality, and, so far, I have never
had 
to. I also don't need to regression test new functionality because it
cannot 
affect existing functionality, which continues to function as it always
has. 
OO encapsulation is a form of "ringfencing" for systems.

To modify existing functionality does NOT mean modifying a base class. It 
means extending (through inheritance) or over-riding existing behaviours. 
Again, only the parts of the system that invoke the modified functionality

need to be tested as the rest of the system is isolated from the changes.

This is, obviously, a different world from COBOL, which was conceived as 
being "easily maintainable" in the days when that was im****tant.

> You need a "yes" answer to all three questions to have well-written
code.

Yes, but the question set is different between Procedural and Object 
Oriented code.
>
> While 'works' is non-negotiable, I'll often often trade 'ultimate 
> efficiency'  for maintainability; e.g., "ultimate" efficiency can often
be 
> best achieved by using lots of GO TOs; but this comes at a
maintainability 
> cost I am generally not willing to pay.
>
> All done, but need more efficiency?  My rule for optimizing may help: 
> First you make it work; only then can you make it work better.

Emphaticaly agreed :-) For both Procedural and OO...

Pete.
-- 
"I used to write COBOL...now I can do anything."