tag:blogger.com,1999:blog-9120169689962505736.post827865444002217474..comments2022-10-25T01:33:38.649+03:00Comments on user interfaces design: Single exit pointMihai Vasilachehttp://www.blogger.com/profile/15904989253787343185noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-9120169689962505736.post-43985014530270507692022-10-25T01:33:38.649+03:002022-10-25T01:33:38.649+03:00I find that almost every post that argues for mult...<br />I find that almost every post that argues for multiple returns omits any mention of using gotos — for the languages that support them — with gotos replacing early returns to jump to a "cleanup:" label placed before the single return to cleanly get a single return without the claimed downsides always mentioned for single returns. Including posts such as this one.<br /><br />That's all I have to say.mikeschinkelhttps://www.blogger.com/profile/11084631234907254594noreply@blogger.comtag:blogger.com,1999:blog-9120169689962505736.post-3617013657268693792022-10-25T01:32:04.812+03:002022-10-25T01:32:04.812+03:00This comment has been removed by the author.mikeschinkelhttps://www.blogger.com/profile/11084631234907254594noreply@blogger.comtag:blogger.com,1999:blog-9120169689962505736.post-22466494670390341622017-04-01T16:49:21.205+03:002017-04-01T16:49:21.205+03:00It's really a matter of taste. Beauty is on th...It's really a matter of taste. Beauty is on the eye of the beholder.<br />I'm not part elite percentage who have amazing memory. <br /><br />Some languages don't have return statements. The if-else could just be expression assigned to variable or the last statement (which in those languages will be the return expression)<br /><br />1)<br />first example One exit point:<br />True - the empty else does not make sense as your throwing a exception (no matter which language)<br /><br />2)<br />second example One exit point:<br />"shouldBeSubmited = true;" has more context than "return true"<br />I already said I have a monkey memory<br /><br />Furthermore I only need one break-point to see the end-result of the function.<br />The same could be said for logging the end result.<br /><br />When the function becomes to verbose refactor the code and solve it as mentioned by bit-twiddler .<br /><br />So I think it's unfair to call us zombie developers just because we have tiny brains.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9120169689962505736.post-63830469020475320272017-02-02T17:26:18.962+02:002017-02-02T17:26:18.962+02:00bit-twiddler – I am sorry, but your three decades ...bit-twiddler – I am sorry, but your three decades of experience has no sway over Martin Fowler. With current need for programmers at any level it is easy to write poor code indefinitely. Besides, you clearly misunderstood his message.<br /><br />That's all I have to say.Anonymoushttps://www.blogger.com/profile/18365744256948938193noreply@blogger.comtag:blogger.com,1999:blog-9120169689962505736.post-20339283875985575082016-07-27T16:45:50.915+03:002016-07-27T16:45:50.915+03:00"
Here is what Uncle Bob said about that:
S..."<br /><i>Here is what Uncle Bob said about that: <br /><br />Structured Programming<br />Some programmers follow Edsger Dijkstra’s rules of structured programming. Dijkstra said that every function, and every block within a function, should have one entry and one exit. Following these rules means that there should only be one return statement in a function, no break or continue statements in a loop, and never, ever, any goto statements. </i><br />"<br /><br />Well then "Uncle Bob" doesn't know what he's on about. This shows a complete mis-understanding of what Dijkstra was talking about (but unfortunately is very common):<br />One entry:<br /> Some languages are able to let you jump into a function some-way through the function. This allows you to, for example, have some initialisation code at the beginning of the function, and in cases where you have pre-initialised the function values, you can skip this initialisation code (or more). This is obviously easy to break.<br />One exit:<br /> These same languages also allowed you to return from the function to a completely other location than where the function was called from. The point here is that Dijkstra was not saying that there should only be one return statement in a function but that <b>you should only return to where the function was called</b>.<br /><br />See <a href="http://programmers.stackexchange.com/a/118793" rel="nofollow">this answer on stackexchange</a> for a better written explanation.<br />See <a href="http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf" rel="nofollow">this pdf</a> for Dijkstra's open letterAnonymoushttps://www.blogger.com/profile/04341093251006557350noreply@blogger.comtag:blogger.com,1999:blog-9120169689962505736.post-1510905310918086212012-06-07T20:16:39.300+03:002012-06-07T20:16:39.300+03:00Martin Fowler's opinion is just that, an opini...Martin Fowler's opinion is just that, an opinion. Opinions are like anal orifices in that everyone has one. <br /><br />I have been a professional software engineer for over three decades, and have spent the majority of my professional career working with OO languages and techniques (I started using OO techniques in 1984 with Ada). To this day, I write single entry/single exit point code that is non-convoluted. <br />Furthermore, guard clauses are reactive coding. Reactive coding is a sign of poor design. For example, operations such as range checking should be performed before value is assigned to a variable, not after it is passed as a parameter.<br /><br />Private methods are not just for code that is used repeatedly within a class. They should be used to decompose public methods into concrete logical steps. Methods that use of multiple exit points are generally poorly factored. Any method that requires multiple exit points is a method that is performing several operations; therefore, it should be factored into smaller methods, each of which performs distinct one operation.Anonymousnoreply@blogger.com