>>I personally have found that most of the stuff they teach you at college is actually based on sound reasoning and experience. For example, whenever I veer from the single function exit -strategy I find that, more often than not, I end up introducing nasty, hard-to-debug bugs.
>>
>>Readability shouldn't really be a problem if you follow the other cardinal rule of keeping our functions short and to the point.
>>
>>These are but few of the cardinal rules of programming, just like always using surrogate keys is a cardinal rule of relational database design (I also had to learn this lesson the hard way many moons ago, and boy was that a painful -- and certainly unforgettable -- one to learn.)
>>
>>You step off the Path of Cardinal Rules at your own peril, because when you do, you may well find yourself in a bewildering jungle without a good (single) exit strategy...
>>
>>Pertti
>
>The stuff that teach you at college is not always the right one as time and science clearly showed many times in history.
>I am asking why it is a bad practice, give me just one solid reason rather than objecting saying it writes in my college book.
>
>Cetin

Cetin,

it is true that college courses sometimes fall behind especially in fast developing topics like computer science. However, I believe that even in these areas there are some fundamental best practices (or philosophies, if you will) that are not affected by change.

A simple example of the value of single exit is restoring the environment at the end of the function. If you preserve environment properties in the beginning, such as currently selected alias, current record numbers/primary keys, etc., then restoring them at one place at the end of the function is clearly less error-prone than writing the same restoration code in two or more exits. It is not unlike normalizing a database schema, where you store a given piece of data in one and only one place. In a similar fashion, with a single exit point you can do "internal function housekeeping" in one and only one place, so that you don't need to remember to propagate a change to many places.

Pertti