Hi Houston,

I understand your position, and there's validity in your statements. You might also, if you haven't already, wish to read my additional response to Jim elsewhere in this thread for a more detailed clarification of my thoughts on this matter.

If your multiple exit points "stick out like sore thumbs", that's a -very- good thing since it makes the readability of the code much easier. And, if we ALL could make them do that, situations like I ran into with my (admittedly over the top) example probably wouldn't occur. Profusely documenting WHY those multiple exit points exist would also go a LONG way (good example: Visual MaxFrame uses multiple exit locations, and Drew documents most of them EXTREMELY WELL).

IMHO, though, most developers aren't that conscientious (sp?) about either of those. If they were, I might not feel as strongly as I do about this issue.

Let me say this: if we were to agree that the multiple exit points all occurred at the top of the module, BEFORE any of the real "meat" of the code, I could live with that.

The other side of this coin is that I really try, whenever possible, not to write modules that are longer than two screenfuls; that way, I don't "oblige the developer" to read miles of code that only executes after "endless tests" of one or more flag variable(s) -- in fact, I use a single variable that ALWAYS has the same name. If more developers factored their code with at least one eye toward future maintainability (present company excluded from that statement -g-), we might not even be having this conversation!

Evan

>>>That sounds like a really bad example of someone not following any rules. In fact, I think your example doesn't count against having multiple exit points, because it wasn't an example of doing that properly.
>
>Hi Evan, I'm with Mike on this one. Your example is one where 'everything' was wrong and multiple Returns merely exacerbated things.
>
>I myself subscribe to the view that multiple Returns are OK. Not too long ago I took on board that some people think this may be a possible weakness, so now I make sure that the Returns stick out like sore thumbs. The opposite side of the coin to multiple Returns is flag variables that prevent code from running combined with endless tests. If 'none' of the code from say 20% of the way down the routine to the bottom needs to be executed, then why oblige a developer to have to read through it?