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)

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.

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


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