Re: conditions and `for` iterations

Chris F Clark <>
Fri, 27 Feb 2009 11:38:46 -0500

          From comp.compilers

Related articles
conditions and `for` iterations (K K) (2009-02-27)
Re: conditions and `for` iterations (Chris F Clark) (2009-02-27)
Re: conditions and `for` iterations (2009-03-07)
Re: conditions and `for` iterations (Chris F Clark) (2009-03-11)
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: Fri, 27 Feb 2009 11:38:46 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 09-02-139
Keywords: code
Posted-Date: 28 Feb 2009 06:34:46 EST

K K <> writes:

> And if there's no performance difference, which version would you
> choose (regarding maintainability, etc.)?

As our esteemed moderator says, for a high-level lanugage (i.e. not a
direct assembler or something else where one expects a 1-1 mapping to
machine code), they should have equivalent performance.

Thus, it comes down to maintainability.

Personally, I would chose the one which takes the least code to write
and has the least nesting.

Thus, if I have a loop with lots of exits I would tend to prefer the
"break" syntax as that will probably be "better" by my criteria. In
contrast, if I have code with lots of reasons to skip to the next loop
I would pick the "continue" style. Often, I have code that has both
and the ordering of the tests is important, so I do a little of one
and then a little of the oter, and back and forth until the loop is

Even better would be to use a tool (often called a "decision table"
processor) like "Logic Gem" or "Statemate" that allows me to describe
the conditions graphically and validate that I have all the options
covered with no ambiguous overlaps and let it worry about the low
level representation.

Hope this helps,

Chris Clark Internet:
Compiler Resources, Inc. or:
23 Bailey Rd Web Site:
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.