if/else loops - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: if/else loops

Quoted text here. Click to load it

Absolutely correct.  One of the big advantages of this concept is that, by
choosing the names properly, you can make your code read almost like prose.
That's a great boon when coming back to code six weeks -- or six months --

That's also one of the reasons I dislike Perl -- special characters don't
scan well.
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Re: if/else loops

Tim Streater wrote:
Quoted text here. Click to load it
Jerry is the expert on that.

Re: if/else loops

Tim Streater wrote:
Quoted text here. Click to load it

Your opinion? Or do you care to cite something.

Quoted text here. Click to load it

Yes, you end up with lots of functions. Lots of well documented easy to
understand (read maintainable) functions.

Another of the principles put forward those long decades ago was that if a
function went "over the fold", meaning that it was longer than two pages of
fan-fold computer paper, about 120 lines, then it was too long. A function
should be able to be read and understood by your average maintainence
programmer almost "at a glance".

I worked partially within a project where these things were strictly adhered
to. IBM customer engineers were contracted out at AU$1,000,000 PA to ensure
this. The language was, believe it or not, COBOL, a language where it is
quite easy to write totally incomprehensible and un-maintainable code.

The main insurance claims update program tallied over a million lines of
code (these were the batch update days) and had a team of a hundred and
fifty programmers working in it, plus the project managers and such. The
road map for the program covered an entire wall.

Every module had exactly one entry point and exactly one exit point. Not a
goto in sight. Even error situations (that we use try-catch these days to
implement) were catered for.

Every module (the "procedure division") was less than one or two pages long.

And, it worked. The program was written and fully unit tested in 80 percent
of the allocated time of two hundred man years. We went out to lunch Big


Re: if/else loops

rf wrote:
Quoted text here. Click to load it


That's tough to do in COBOL! :-)

Quoted text here. Click to load it

I'll also add, it's common in C code to try to hold functions to about
20 lines or less.  That's not a hard rule - but if you're running over
that, you should at least examine your functions to see if you're doing
too much in one function, and should possibly split it into multiple ones.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: if/else loops

Jerry Stuckle wrote:
Quoted text here. Click to load it

Not really. If a fiunctiuon is only called from one placem , why=y bother
Its just as easy to write a large comment and add a page
break, and let someione know that here the code is entering a new
functional phase
and if there are issues with variable scope. in C you can define a new
block like this
int new_variable;
some code...

Never confuse clarity of writing, with how the program flow is organised.

COBOL had its own restrictions: typically subroutines were rolled in and
out of memory. To large a subroutine and no more core...

Re: if/else loops

Tim Streater wrote:

Quoted text here. Click to load it

Exactly. All this 'perfectly structured programming' leads to the LISP

Lots of Indented Superflous Parentheses..

Re: if/else loops

Scott Johnson meinte:
Quoted text here. Click to load it

You don't, since "if-else-loops" don't exist.

Quoted text here. Click to load it

I prefer the second approach. Saves indentation...


http://web.gregorkofler.com - vxJS, a JS lib in progress

Site Timeline