Hi Evan,

You got my sympathy in that story, for sure.
My personal nightmare was an important FORTRAN business program that I was handed for revision, only to find that the originator had used the standard deck of cards for all variable names. So I had stuff like 'IF Jspades = Aclubs' and other crap you can imagine.

But, really, I do wonder at using one terrible experience as the reason for never deviating from a 'single exit point' standard.

I still have a problem with the apparent assumption that multiple exit points is equivalent to bad design. Your nightmare scenario was clearly bad design, bad programming and bad coding all rolled into one.

Are you possiby starting off with that assumption? In other words, does the existence of multiple exit point immediately cause you to conclude that there is bad design in that program?

If it does, I think you might be in error.

cheers


>Hi Jim,
>
>SET SOAPBOX ON
>SET BAD MEMORIES ON
>
>
>I ***ABSOLUTELY SUBSCRIBE*** to the "one exit point" approach, and *ALL* my code follows this.
>
>Why? Simple answer -- because someone besides myself might have to read AND understand my code one day.
>
>Example: I was asked about seven years ago to "finish" a employee timecard system written in FoxDos25 and running over LAN Mangler -- err, LAN Manager 2.0 for a multinational satellite consortium by a (supposedly) professional Fox developer and consultant in the Washington, DC area. This developer had been working on this project for six and a half months; I was to be given three and a half weeks to finish it, without the possibility of a rewrite, or the company's IT director lost his job.
>
>Picture in your mind an employee's time card for a week, with two levels of project codes on the left, one control for each day's time expenditure, and the total. Now picture fifteen lines of these, plus some other controls for status and so forth. Total number of controls on this form: one hundred and sixty-four (164). This form took almost SIXTEEN MINUTES to load (remember, this is a DOS application...)
>
>Now, imagine my surprise, when I looked at the code for this form, in finding over 5800 lines of code behind EACH of the 164 controls. That's not a misprint -- 5800 lines. NONE of these lines were indented or commented. There was NO white space. The first 200 or so lines were all function calls to other places in the code. All the commands were in the four-character mnemonic style popularized in dBASE II (in the early 1980's). Hmmm...5800 lines of code times 164 controls...this explained the long load times...
>
>POINT OF THE STORY HERE: as if that wasn't enough -- I soon discovered that each control contained EXACTLY THE SAME 5800 LINES OF CODE. The developer simply inserted a RETURN command at the desired "exit point" for that control. Sometimes that exit point was in one of the above named subroutines; sometimes it was below the function call; sometimes it was based on the result of the function, which invariably called OTHER functions, which might or might not have RETURN statements in THEM...
>
>Well, you get the idea.
>
>*** THAT'S *** why this standard is important.
>
>
>SET BAD MEMORIES OFF
>SET SOAPBOX OFF
>
>(epilogue: I ended up rewriting just that form, desnippetizing those 5800 lines to less than 2500, including comments and white space, in a surrounding PRG, added some indexes to the table where the form saved its data, and reduced the load time to **thirty-five seconds**. The IT director kept his job, and I got a six-month contract.)
>
>
>>Continuing PeterDeV's quest towards a set of 'excellent coding standards'...
>>
>>What is the value/purpose of "one exit point per code unit?"
>>
>>Isn't it time that this old chestnut was retired?
>>
>>I don't see an iota of **real** value to the practise, but I do see problems.
>>
>>Why do you follow the practise?... if you don't, why don't you and what static have you heard from others about it?
>>
>>Anticipating interesting replies,
>>JimN