The single entry issue has apparently been resolved; I can't think of a single modern language that allows calling into the middle of a routine. But it's interesting that after so many years there is no general consensus on single exit versus multiple exits. The PMD static analysis tool for Java will (by default) generate a warning for multiple exits http://pmd.sourceforge.net/rules/controversial.html . In Steve McConnell's book "Code Complete, Second Edition" http://www.cc2e.com/ he recommends minimizing exits, but using multiple exits when that improves reliability. Since he has reviewed work by thousands of developers using many languages and styles his recommendations carry significant weight. I understand that Martin Fowler also makes a similar recommendation in his book "Refactoring: Improving the Design of Existing Code" http://martinfowler.com/books.html#refactoring , although I haven't gotten around to reading it yet.
Based on my own experience I do it either way depending on what keeps the code simpler and easier to understand. One common problem with using a single-exit design is that it often forces you to use a mutable variable, or at least separate variable declaration from initialization. For most of the code I write now I force myself to use immutable ("final" in Java) variables in 95%+ of cases and have found this delivers huge benefits in reliability and maintainability. Managing state well is just as important as managing control flow. I haven't seen multiple-exit designs cause any later maintenance defects that a single-exit design would have prevented.
I'm not sure what problems edw519 has seen over the years, but perhaps many of the maintenance defects he saw were caused more by long routines than by multiple exits. If you keep most routines short enough to fit on a single screen that makes it easy for maintenance programmers to follow the flow regardless of the number of exits.
"...keep most routines short enough to fit on a single screen..."
Absolutely.
What invariably seems to happen is that 30 lines of code turns into 300 in a few years. Seems like most enhancements are inserted "black box style" so as to not "mess around with that which we don't understand and don't have enough time to learn".
Based on my own experience I do it either way depending on what keeps the code simpler and easier to understand. One common problem with using a single-exit design is that it often forces you to use a mutable variable, or at least separate variable declaration from initialization. For most of the code I write now I force myself to use immutable ("final" in Java) variables in 95%+ of cases and have found this delivers huge benefits in reliability and maintainability. Managing state well is just as important as managing control flow. I haven't seen multiple-exit designs cause any later maintenance defects that a single-exit design would have prevented.
I'm not sure what problems edw519 has seen over the years, but perhaps many of the maintenance defects he saw were caused more by long routines than by multiple exits. If you keep most routines short enough to fit on a single screen that makes it easy for maintenance programmers to follow the flow regardless of the number of exits.