on goto
in [General Programming]
|
From: Richard Heathfield on 11 May 2010 21:02 Daniel T. wrote: <snip> > > I think part of the problem here is that I'm being painted as some sort > of SESE bigot and attacked from those grounds. I don't think you're in any danger of being called a SESE bigot as long as I'm around. I'm a much easier target. :-) <snip> -- 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: pete on 11 May 2010 22:00 Richard Heathfield wrote: > > Daniel T. wrote: > <snip> > > > > I think part of the problem here is that > > I'm being painted as some sort > > of SESE bigot and attacked from those grounds. > > I don't think you're in any danger of being called > a SESE bigot as long > as I'm around. I'm a much easier target. :-) I find SEME to be less objectionable in functions which are small enough so that you can't look at one exit without noticing the all the rest of the exits. -- pete
From: James Dow Allen on 11 May 2010 22:08 On May 12, 1:18 am, Keith Thompson <ks...(a)mib.org> wrote: > 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. I think we can assume the present company will be diligent enough to inspect the code for correctness, test it adequately, or both. The issue is *readability* and all other things being equal, the code with fewer elements is faster and easier to read. Now I'm *not* saying that goto foo; is no more troublesome than pogo +=1; just because they use the same amount of ink! I avoid goto's; I avoid inside returns; but I *don't* consider that they have infinite cost! But let's agree that much of this is a matter of taste. I like Ernest Hemingway: > Nick stood up. He was all right. Perhaps Mr. Heathfield prefers Joseph Conrad, who I find almost unreadable. James Dow Allen
From: Lie Ryan on 12 May 2010 00:33 On 05/11/10 18:26, Richard Heathfield wrote: > Seebs wrote: >> On 2010-05-11, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >>> Seebs wrote: >>>> I'm working on a roguelike game. I have a dungeon, which consists >>>> of levels, >>>> and the levels are not necessarily all the same size. Each level is >>>> itself >>>> a 2D grid of points. It is quite conceivable to want to ask the >>>> question >>>> "is there any point in the dungeon which contains a foo". At this >>>> point, >>>> the obvious thing to do is >>>> for each level >>>> for each row >>>> for each column >>>> is there a foo? >> >>> No, that's a terrible way to do it. >> >>> You already have a list of foos, properly ordered for fast searching. >> >> No, I don't. > > Then I suggest you get one. > If I'm searching for all cells whose sprite size is 56 pixels (e.g. 7x8), do I create a list of all integers in the program?
From: Seebs on 12 May 2010 02:19
On 2010-05-12, Daniel T. <daniel_t(a)earthlink.net> wrote: > I think part of the problem here is that I'm being painted as some sort > of SESE bigot and attacked from those grounds. Sounds like crossed wires, I guess -- I didn't think you were any such thing. But I may have missed the attribution on a post at some point. > { > 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. Yeah. I am usually wary of such things. I do actually like to do: int foo(...) { if (condition) return -1; if (condition) return -1; /* lines of code */ return meaningful_value; } I feel that getting the "we won't even try to do something" cases out of the way early on leads to more comprehensible code later, if only because of the reduced indentation. But apart from that... I am not a big fan of "exits scattered all over the place". I am okay with "exits at the beginning of a clearly coherent logical block, in circumstances where all other processing is necessarily impossible". -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! |