Apr 23, 2013, 3:57 PM
Post #5 of 8
Simplification is achieved by allowing early return (a violation of structured programming)
I may be off-topic, but I strongly object to the idea that early return is a violation of structured programming.
Yes, Niklaus Wirth, a great computer scientist and one of the fiercest proponents of structured programming, refused to include early returns from Pascal and other languages that he designed (including, I think, Modula and Oberon).
But I think he was wrong on that (I know, who am I to claim that?), and that actually might partly explain why none of the languages he developped on that mindset really succeeded in real life programming (OK, Algol may be an exception, but it still did not last very long). Nothing compared to the longevity of Lisp, C, C++, Java or... Perl.
As far as I know, Dijkstra, another great computer scientist heavily involved in the same debate and the famous author of the "Goto considered harmful" article (although that somewhat provocative title has apparently been chosen by Wirth) never objected to early return. And Donald Knuth also made a case against gotos that go backwards, but not against early returns.
I also (thing to) remember having read an article by Larry Wall (I think it was him, I hope I am not wrong), explaining that an software program can quite often be considered as a decision tree and that an early return is a natural thing to do when some conditions are met. Getting rid of the special cases early usually makes programs much easier to understand than straightjacket-type of deeply nested if/then/else constructs.
In brief, I am totally on the side of structured programming, but I think that early returns (or early exits) often simplify considerably the logic of programs. And I never use gotos (except in a specific proprietary language that I am using and in which it is just the only way of making an early return), but, in Perl, I use very often the last and next instructions (which are nothing but early returns constructs).