I am adding this thread for 2 reasons: the original thread has become very cumbersome and the debate got out of hand to the point where someone referred to my arguments as "idiocy". This is unfortunate in a forum like this. I come here much like everyone else, to share and learn and take a nice break from time to time.
Perhaps I didn't explain myself well enough in the previous thread. Well, here goes...
I wrote the Fixed Assets module for a division of CSC in 1987. Everything went pretty much as planned (analysis, design, coding, testing, deployment) until the code review. The beta customers were very happy, but my code could not be accepted into the repository because it was in violation of their standards. The minor violations (usually variable names) were easily fixed, but the biggest violator? Early exits. I thought that this was ridiculous and used many of the same arguments people used in the previous thread: less code, cleaner, faster, easier to read, etc., etc., etc.
The response... "You don't understand. We have a backlog of 495 bugs on the bug list. The original cause of about one third of these was the original programmer violating "single entry/single exit".
This was hard for me to wrap my head around. How could cleaner, simpler code be harder to maintain? Because you can't count on those who follow you to be competent. So there are standards that a lot of people much smarter than me came up with to minimize the problem down the road.
I have fixed thousands of bugs since then and my lesson was well learned. About half the bugs I've seen were caused either by poor variable naming or single entry/single exit violations. Sure, ther program worked fine at first, but after many mods, things got lost. Structured programming was meant first and foremost to extend the life of the code by avoiding this.
So I ask any programmer, "How long do you expect what you're writing today to be in production? What changes will be needed in the future? Who will apply them? Will they have enough time to do it right? Will they be competent?"
(Hint: The answer to all of those questions is, "I don't know.")
That's why I offered a few "tips" related to structured programming. I didn't make any of this up. I speak from the experience of cleaning up lots and lots of messes. Your code may look beautiful today, but who knows how others will mangle it down the road.
Do what you want with my input, just like any other. Take it or leave it. Just a little offering from a digital canary in the coal mine.
Again, I haven't seen this problem in the wild, and I have trouble seeing how it could exist. My functions tend to be actual functions - they don't touch state outside of the function (and lexically enclosing scopes, for closures) - and so if a function exits early, it just gives the wrong answer. This is caught immediately by the unit tests; there's no place for bugs to hide and cause problems later.
The one exception is UI-intensive code, which often requires state because users expect their UI to change in response to distant changes. For this, any "hidden" state is clearly documented and included in the tests, just as if it were the return value of the function. All other destructive updates touch the UI, so they're fairly quickly visible when screwed up (and I have individual tests for subwidgets, that test the GUI components in isolation).
I see a lot of the tenets of structured programming as holdovers from when it was okay to mutate variables. It's state that's the true cause of bugs, not single-entry-single-exit.