Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
One exit per procedure/function/codeblock to what purpos
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00835552
Message ID:
00835880
Views:
26
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.
Evan Pauley, MCP
Positronic Technology Systems LLC
Knoxville, TN

If a vegetarian eats vegetables, what does a humanitarian eat?
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform