on goto
in [General Programming]
|
From: Nick Keighley on 11 May 2010 03:30 On 11 May, 06:26, Richard Heathfield <r...(a)see.sig.invalid> wrote: > My preference for SESE is rooted in some truly appalling SEME > code that I've had to maintain in the past. but MEME is even *more* fun. But that needs a truly awesome assemly programmer.
From: Richard Heathfield on 11 May 2010 03:42 Phil Carmody wrote: > Richard Heathfield <rjh(a)see.sig.invalid> writes: >> Willem wrote: >>> Let's take your example to make my point: >>> Richard Heathfield wrote: >>> ) found = 0; >>> ) for(x = 0; !found && x < xlim; x++) > >> No, the benefit of SESE is that you know that every loop has a single >> entry point and a single exit point. > > It can exit after !found fails, or after x < xlim fails. Nice try. They are, however, effectively the same exit point. -- 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: Richard Heathfield on 11 May 2010 03:49 Nick Keighley wrote: > On 11 May, 06:49, Richard Heathfield <r...(a)see.sig.invalid> wrote: >> Seebs wrote: > >>> Okay, here's a nice concrete case from code I've actually written once >>> upon a time, or something much like it. >>> 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. >> Search the list. >> >> If you don't already have a list of foos, then you are excusing one flaw >> in your program by the existence of another flaw in your program. Two >> bugs don't make a sensible programming strategy. > > Richard <no-name> > [response to same post] > > > **** <essentially the same reply as mine, although I didn't call Seebs a complete idiot> > **** > > good grief, they're agreeing... I didn't plonk the guy for always being wrong. (Even if he *were* always wrong (which IIRC he wasn't and presumably isn't), that wouldn't be a particularly good reason to plonk him.) No, I plonked him for being a troll. -- 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: Richard Heathfield on 11 May 2010 04:04 Seebs wrote: > On 2010-05-11, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> Bait away. My preference for SESE is rooted in some truly appalling SEME >> code that I've had to maintain in the past. > > Having read posts by Mr. Nilges, why do you persist in using English, when > it is clearly a language which supports apallingly bad writing? Najlepszy punkt. Moja obrony jest fakt, że oprócz prawdopodobnie C, nie wiem również dość wszelkich innych wersjach językowych skutecznego porozumiewania się w nich. Moje polskie, na przykład, jest po prostu odmianą. [Tr: Excellent point. My defence is that, apart from perhaps C, I don't know any other languages well enough to communicate effectively in them. My Polish, for example, is simply ghastly.] My apologies for the non-ASCII characters in my first paragraph, above. > Which is to say: The fact that bad code can be written which can be fairly > described as using multiple exits does not in any way establish that multiple > exits are at fault. It is quite possible to write deeply illucid code which > uses single exits. Multiple exits are not the underlying source of that > problem, any more than C is at fault for all the atrocious C out there. The underlying source of that problem, as far as I can make out, is what I have seen described as the "pigeon-hole" approach to programming - the idea that a programmer's task is simply to put the right numbers in the right places at the right time, and that nothing else matters. Such a programming style used to be commonplace (see the story of Mel in TJF for a somewhat more positive slant on "pigeon-hole" programming). But, in my view, structure and abstraction provide real and lasting benefits for large, maintained programs. Yes, it's a line, not a binary - to talk about "structured" vs "unstructured" code is to imagine a polarity that doesn't really exist in the real world. But I have found that leaning heavily towards the "structured" end of the line yields real benefits in clarity and therefore maintainability. Sometimes it makes sense to stick to style rules even when departing from them would do no particular harm and might even do a little good; sticking to a known-good strategy means spending more time thinking about the problem domain and wasting less time on thinking about how to code it. (I know you won't draw the erroneous conclusion that I am advocating spending /no/ time on thinking about coding.) <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: wolfgang kern on 11 May 2010 03:55
Nathan Baker wrote: >> Ok Nate, we had enough discussions on this matter since HLLs >> entered our progamming world ... >> We better give up arguing and let the 'faster' programmers >> be proud of their 'maintainable/foolproof-readable' sources >> which are awful detours with "abstraction layers" while the >> few hardware freaks like me work on "really existing things" :) > The CPU experiences a nightmare while executing HLL code. > Perhaps there is an instructive way for us to demonstrate this fact? Even we could try this one more time, I daubt that 'fundamental' HLL-coders may listen at all. The believe in their holy compilers seem to be very strong :) I think demonstration of the bloated redundance isn't required, disassemble whatsoever you find (windoze+lunix/app+sys) and see as of immediate all the weird detours created by 'a tool'. The few programmers who know both worlds may be aware and create lesser bloated and faster code even with HLL. __ wolfgang some believe in god, many in gold, a few in logic, and HLL-coders in their compiler. |