on goto
in [General Programming]
|
From: Richard Heathfield on 11 May 2010 18:05 Willem wrote: <snip> > In this specific case, Early-Exit seems to have the > advantage. In this highly artificial and trivial case, I agree (just), on that one minor point. In general, however, I have found that SESE leads to clearer and more maintainable code. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Leigh Johnston on 11 May 2010 18:33 "Richard Heathfield" <rjh(a)see.sig.invalid> wrote in message news:TvadnZt0lNsHSXTWnZ2dnUVZ8hmdnZ2d(a)bt.com... > Willem wrote: > > <snip> > >> In this specific case, Early-Exit seems to have the >> advantage. > > In this highly artificial and trivial case, I agree (just), on that one > minor point. In general, however, I have found that SESE leads to clearer > and more maintainable code. > > -- > Richard Heathfield <http://www.cpax.org.uk> It is painfully obvious that you are a stubborn old C hacker. SESE is a relic of older languages such as C. SEME is desirable in a more modern language like C++ where SEME is de rigueur (RAII, exceptions). If you disagree then please stop cross-posting your replies to comp.lang.c++ and restrict your dated views to comp.lang.c. /Leigh
From: Seebs on 11 May 2010 18:40 On 2010-05-11, Leigh Johnston <leigh(a)i42.co.uk> wrote: > It is painfully obvious that you are a stubborn old C hacker. SESE is a > relic of older languages such as C. SEME is desirable in a more modern > language like C++ where SEME is de rigueur (RAII, exceptions). If you > disagree then please stop cross-posting your replies to comp.lang.c++ and > restrict your dated views to comp.lang.c. And your flamebait crossposting is somehow less bad? Sheesh. I suppose, though, that's what we get from older users; clearly, more modern users (preferably still in diapers) wouldn't post like that. :P -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Daniel T. on 11 May 2010 20:41 Seebs <usenet-nospam(a)seebs.net> wrote: > On 2010-05-11, Daniel T. <daniel_t(a)earthlink.net> wrote: > > > ... "What if the situation is exactly such that the best solution is > > nested for loops and an early return?" To that I answer, then use > > nested for loops and an early return. What is your point? > > My point is: In the case where that loop would have been written at > all, the multiple-exit variant would be by far the cleanest solution. > Every alternative provided has either been noticably more complex, or > been reliant on an obviously-different data structure than the > original addressed. > > I think in this case I'm pretty much in agreement with you on the > issue; the correct thing to do is make a decision in each case based > on the circumstances at hand. I think part of the problem here is that I'm being painted as some sort of SESE bigot and attacked from those grounds. While I freely admit that I probably use SESE a little more often than the average programmer, I don't think that the fact that I use it more often should paint me as some sort of zealot. That said, I just had to deal with a function written by someone else (in Objective-C) that was in the format: { if () { /*lines of code*/ } else { /*lines of code*/ if () { /*lines of code*/ return; } /*lines of code*/ if () { /*lines of code*/ } else { /*lines of code*/ } /*lines of code*/ } if () { /*lines of code*/ } /*lines of code*/ } There was enough code distributed in this control structure (some 50 lines worth) that the 'return' was completely buried (at least to my eyes. Even looking at the above, I find the return hard to spot.) I waisted a half-hour trying to figure out why some stuff I added to the end of the function only worked intermittently.
From: Daniel T. on 11 May 2010 20:47
Keith Thompson <kst-u(a)mib.org> wrote: > Nick Keighley <nick_keighley_nospam(a)hotmail.com> writes: > [...] > > I think he proposed > > > > for (loop_incomplete OR not_found) > > for (loop_incomplete OR not_found) > > for (loop_incomplete OR not_found) > > if ... found <- T > > > > that is an extra boolean (and some extra testing) > [...] > > (In the above, "he" refers to Richard Heathfield; the above is obviously > a pseudocode summary of what Richard posted.) > > One problem I have with the above is that the "OR not_found" > condition has to be written 3 times. I'm not very concerned > about the CPU time spent testing the variable. > I'm more concerned > about the conceptual complexity of having to write the same thing > multiple times, with the attendant risk that a typo in one of the > three occurrences (forgetting the "!" operator, for example) won't > be caught by the compiler. And one problem I have with it is that "for" has to be written 3 times. I'm concerned about the conceptual complexity of having to write the same thing multiple times, with the attendant risk that a typo in one of the three occurrences (incrementing the wrong counter in the wrong loop, for example) won't be caught by the compiler. It seems our concerns are very much the same, but mine is a problem with *both* examples. :-) |