Hi Trey,

Just to clear up one thing from this end...

Your 'nightmare' (described below) is a good example of something that I would be compelled to clean up too!
It was obviously NOT "designed" with maintainability in mind.

I'm still of the opinion that good well designed code CAN have multiple exit points and still be good well designed code.
In fact I still say it is usually better to encourage multiple exits especially from the standpoints of readability/maintainability (which in essence are the same thing in my eyes).

In other words, and I think as you already do, THINK ABOUT IT and do what's best for the situation at hand.

cheers

>>Hi Trey,
>>
>>I think the most significant thing I read in your reply is that you retain flexibility and do deviat from the practise under some circumstances.
>>
>
>Absolutely
>
>>I have some comments/questions under your items below...
>>
>>>These are the reasons I prefer to follow this standard:
>>>
>>>1. Encapsulation
>>>If you have several exit points in a method/function, it's a pretty good sign that you need to refactor somehow, .....
>
>>I really wonder WHY it even *might* be so that something with multiple exit points needs refactoring?
>>Seems to me that THE reason would be that it is 'bad form' to have multiple exit points. The question I have is why IS it bad form? I think it is fine form, myself. When I need to, I'll get into the reasons I think so.
>>
>
>It doesn't mean it has to be refactored. But it is a warning flag. I once ran across a calculation method that did had code for about fifty separate calculations, of which it used only one, based on the parameters passed. Each calculation was different enough to warrant it's own big chunk of code, and in each chunk, there were multiple return points, before each of which was [supposed to be] a CleanUp() call. If they had all been included as they should have been, there would have been around 150 calls to the CleanUp() function. It was a major PITA to maintain. I refactored it to branch to individual calculation methods, which in turn were refactored to have one CleanUp() call before the one exit point. And there was much rejoicing ("yay")
>
>Here's a case where all of the calculation code worked just fine, but because it did get updated often enough, it was a maintainence nightmare. And, in case you're wondering, I used one exit point in the branching logic that replaced the code for the big calculation method.
>
>>>
>>>2. Maintenance.
>>>One should never assume that he will be the only programmer working on a piece of code, or that the code is perfect as is. Things change.
>>>I've seen the following numerous times:
>>>
>>>-- I need to add code to do something at the end of an existing method, based on various return codes. .....
>>>
>>Well it really ought to be the rare case where something to be added at the END of a process would still need to process in those cases when exit was done early.
>
>This is true, but that all depends on why it exited early.
>
>>And if it was actually needed in earlier processing within such code, what would stop you from putting it there instead.
>
>The 150 instance flashbacks.... <s>
>
>>Again here it seems possible that the reason you find the need to convert early returns to vars is that you are ALSO 'correcting' the "bad form" you've come across rather than because you NEED to to get working code.
>>
>
>>>-- Tables/cursors remain open that should have been closed or record pointers do not get reset ....
>>
>>Well that would be the result of sloppy coding, would it not? I mean a single line saying =Cleanup() would solve that handily, would it not?
>>
>
>
>From example above, you can see one big reason why I view multiple returns and the maintenance problems they can cause to be sloppy coding. Even if that one big calc method had been coded properly (i.e., with the cleanups), the maintenance would have been horrendous.
>
>Having one exit point doesn't do anything toward getting you toward working code in and of itself.
>To me, the real benefit comes from maintainability. Never assume that you are working with programmers as conscientious as you. I mean, you can have spaghetti code that works just fine, but spaghetti code is not good programming practice, either.
>
>>I'm afraid I remain unconvinced that there is any real benefit to a single exit point so far. But my mind can be changed.
>>
>>cheer