Hi Evan,

You've clarified things straightforwardly.

I certainly agree that programming/code "style" is very highly personal and subjective.

And one thing I try to do (bet you do too) is to 'follow' the same style in any program that I am called on to modify (unless it is like the nightmare you described), even if it's way off my own style. My take is that it is worse for the next guy to have 2 (or 3 or 4...) styles to ferret through just to get to know/understand the code.

cheers

>Hi Jim,
>
>SET SNIP ON
>>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?
>SET SNIP OFF
>
>No, I don't assume or conclude that because there are multiple exit points that the program is poorly designed. I stated that "I don't do that", then explained why I chose not to.
>
>My *personal style* is to have a single exit point, and that exit point is ALWAYS the last non-comment line of the module. That way, if I (in one of my increasing number of "senior moments") somehow *forget* to put it in, the code won't break. My statement was that I absolutely support this approach and don't believe it should be "put to rest".
>
>By way of (further) explanation, if I were to be handed some code that looked like this:
>
>

>*-- Check for my condition
>IF SomeCondition
>  RETURN
>ENDIF
>
>*-- Check for some other condition
>IF SomeOtherCondition
>  RETURN
>ENDIF
>
>*-- Do the important stuff
>
>--- more code here ---
>
>*-- Get out and go home
>RETURN
>

>
>my reaction would be "okay, *I* wouldn't have done it that way, but it's *readable*, it's *commented*, it can be *easily modified*, and *it runs* -- therefore, it's *fine*."
>
>I have several other "personal style items"; for instance, always declaring local variables at the top of each module (never in the middle of the code). Does that mean that I think code which declares local variables throughout as needed is "poor" or "bad" code? ABSOLUTELY NOT -- it's just a different style. *I* happen to think it's harder to follow for future developers looking at that code, but that's *MY* way of looking at it and doesn't mean that it's the "correct" approach.
>
>I try hard not to generalize when we're talking about "style of coding". What's most important to me is that code is (these are in no particular order):
>a) operational, and works as advertised
>b) readable, without the use of abbreviations, mnemonics, or massive macro substitution
>c) well commented, especially where common rules and/or conventions are broken
>
>After that, IMHO, it's mostly a style issue and relatively unimportant in the big picture.
>
>Hope that helps clarify my position.