Re: if/else loops

Jerry Stuckle wrote:
rf wrote:
Tim Streater wrote:
In article <KgqLl.8350$y61.4746@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
"rf" <rf@xxxxxxxxx> wrote:

Jerry Stuckle wrote:

I keep my function short and to the point, also. But I also don't
strew return statements all over the place.
When I learned OOP many decades ago the rule was exactly one entry
point to a function (at the start) and exactly one exit point (at
the end). The "teaching" languages did not *have* a return
statement, much less a goto statement.
A piss-poor rule.

Your opinion? Or do you care to cite something.

If something inside an if (for example) becomes so non-trivial as to
cause indentation problems then that something probably deserves to
be in its own function.
So you end up with trillions of functions each doing damn-all. And how
do you give them sensible names to cover what little they are doing?

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


Exactly.

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.


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

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 Time.


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.


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...
.

Relevant Pages

  • Re: if/else loops
    ... 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 and had a team of a hundred and fifty programmers working in it, plus the project managers and such. ... Every module had exactly one entry point and exactly one exit point. ... The program was written and fully unit tested in 80 percent of the allocated time of two hundred man years. ...
    (comp.lang.php)
  • Re: if/else loops
    ... quite easy to write totally incomprehensible and un-maintainable code. ... The main insurance claims update program tallied over a million lines of ... Every module had exactly one entry point and exactly one exit point. ... of the allocated time of two hundred man years. ...
    (comp.lang.php)
  • Re: Strange Fortran version
    ... "ENTRY lable" was common in some Fortran IV subroutines and probably ... Fortran compilers (many were written as a higher exercise in M.SC tasks ...
    (comp.lang.fortran)
  • Re: Trigraphs & entry [OT]
    ... The entry keyword was intended to provide subroutines with more than ...
    (comp.lang.c)
  • Re: Entry point of a DLL
    ... I've made a DLL from fortan code using gfortran. ... Is there a way to make that there's only 1 entry point in my DLL (only ... Make some of the subroutines internal routines. ...
    (comp.lang.fortran)