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.

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, whether it be to break it up into more specific methods/functions (e.g., handling calculations based on different criteria - the branching logic should be to call disparate functionality), or to rethink the logic behind it (e.g., returning a friendly description for an error code - put it in a lookup table)

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.

>
>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. Typically, I'll just write a new method as a handler, and pass the return code to it. With multiple exit points, these have to be converted to vars. Not too bad to do once or twice, but when you have to do it across a large number of methods, it becomes a real PITA.
>
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.
And if it was actually needed in earlier processing within such code, what would stop you from putting it there instead.
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 because exit points occured prior to any clean up code. Sometimes the clean up code is repeated, which is also bad IMNSHO, but even then it's not always done prior to every return.

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?

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

>
>
>That said, for readability, I will break with tradition if I need to bail out before a process is even attempted. I do this primarily to avoid having the whole method inside a big IF..ENDIF (or worse, DO CASE..ENDCASE) e.g.
>

*-- DoSomeClientProcessing()
>*  returns integer code
>LParameters tiClientID
>
>Select * From client Where client_id=tiClientID Into Cursor cuClientInfo
>If RecCount("cuclientinfo")=0
>   *-- BAIL
>   Return CLIENT_DOES_NOT_EXIST_LOC && constant
>EndIf
>
>** lots of processing code here and down....

>
>
>>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