tag:blogger.com,1999:blog-4084458860381242516.post7961105275306293964..comments2023-11-26T20:18:14.351-08:00Comments on Putting the tea into team: Ivan Moorehttp://www.blogger.com/profile/09119134602348298270noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-4084458860381242516.post-88925378019307467252008-11-11T16:44:00.000-08:002008-11-11T16:44:00.000-08:00As you say, the section on structured programming ...As you say, the section on structured programming is very short. It only talks about one structured programming rule: 'every function, and every block within a function, should have one entry and one exit'. The author says that while the rule provides little benefit in small functions, it provides significant benefits in larger functions. I agree with you that they should justify their claim.<BR/><BR/>*** In <A HREF="http://www.amazon.com/Essential-Java-Style-Patterns-Implementation/dp/0130850861/ref=sr_1_3?ie=UTF8&s=books&qid=1226450264&sr=1-3" REL="nofollow">Java Style - Patterns for Implementation</A>, while dismissing the rule as an anachronism, Jeff Langr implicitly gives us some idea about why the rule is useful in long methods:<BR/><BR/><I>Somewhere [in Dijkstra's paper "Goto Statement Considered Harmful"] I also remember a platitude about not returning out of a routine in its middle. Of course that was back in the days when functions or subroutines were dozens of lines long...within the context of a brief method, then, a return statement is not nearly as obscured as one within a large nesting of other statements. <A HREF="http://c2.com/cgi/wiki?GuardClause" REL="nofollow">Guard Clause</A>, one of my favourite formatting patterns, promotes early exist from methods.</I><BR/><BR/><BR/>*** In <A HREF="http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?ie=UTF8&s=books&qid=1226450236&sr=1-1" REL="nofollow">Code Complete</A>, Steve McConnel, does gives us at least some concrete justification for the rule:<BR/><BR/><I><B>Minimise the number of returns in each routine</B> - it's harder to understand a routine when, reading it at the bottom, you are unaware of the possibility that it returned somewhere above. For that reason, use returns judiciously - only when they improve readability.</I> - Btw, he does advocate using <A HREF="http://c2.com/cgi/wiki?GuardClause" REL="nofollow">Guard Clause</A> to enhance readability and simplify complex error processing)<BR/><BR/><BR/>*** In <A HREF="http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091/ref=sr_1_1?ie=UTF8&s=books&qid=1226450096&sr=8-1" REL="nofollow">Implementation Patterns</A>, Kent Beck provides a more high-level justification:<BR/><BR/><I>Back in the old days of programming, a commandment was issued: each routine shall have a single entry and a single exit. This was to prevent the confusion possible when jumping into and out of many locations in the same routine. It made good sense when applied to FORTRAN or assembly language programs written with lots of global data where even understanding which statements were executed was hard work. In Java, with small methods and mostly local data, it is needlessly conservative. However, this bit of programming folklore, thoughtlessly obeyed, prevents the use of <A HREF="http://c2.com/cgi/wiki?GuardClause" REL="nofollow">guard clauses</A>.</I><BR/><BR/>Cheers.Philip Schwarzhttps://www.blogger.com/profile/02202819885723986161noreply@blogger.com