Stephen Chalmers wrote:
[color=blue]
> "Thomas 'PointedEars' Lahn" <PointedEars.de@nurfuerspam.de> wrote in message
> news:40D1BED6.7040003@PointedEars.de...[color=green]
> > Stephen Chalmers wrote:[color=darkred]
> > > "Shawn Milo" <newsgroups@linurati.net> wrote in message
> > > news:c2fe7ed0.0406020331.24175fa8@posting.google.c om...[/color]
> >
> > Please do not write attribution novels.
> >[color=darkred]
> > >> for (iCount=0; iCount<drpBox.length; iCount++){
> > >> if (drpBox[iCount].value.match(regEx)){
> > >> drpBox.selectedIndex = iCount;
> > >> break;
> > >> }
> > >
> > > Don't use break to terminate a loop; make the test condition fail -
> > > that's why it's there:[/color]
> >
> > Nonsense. That's what the "break" statement is good for: exiting loops
> > without knowing the test condition and breaking switch()es if the next
> > case-condition should not be matched or its default statements should
> > not be executed. I suggest you read on the language we are discussing
> > about.
> >[/color]
> What exactly might I learn should I read-up on this Mickey Mouse variant of
> the proper languages I have been using for years? If you read any reputable
> text book on any C-derived language (assuming you can still find one), it
> will tell you that 'break' and 'continue' are frowned upon by programmers,
> save for the use in the switch statement for which it was designed.[/color]
O'Reilly beg to differ:
"In a simple loop, the test expression is the sole factor that determines when
the loop stops. When the test expression of a simple loop yields false, the loop
terminates. However, as loops become more complex, we may need to arbitrarily
terminate a running loop regardless of the value of the test expression. To do
so, we use the break and continue statements."
<url:
http://skaiste.elekta.lt/Books/O'Reilly/Bookshelfs/books/webdesign/action/ch08_06.htm
/>
As does Sun:
<url:
http://java.sun.com/docs/books/tutor...ts/branch.html />
[color=blue][color=green]
> > Nonsense. That's what the "break" statement is good for: exiting loops
> > without knowing the test condition[/color]
>
> If you wrote the code, how can you not know the test condition?
> To any code-maintainer, the test condition should indicate the only
> reason(s) for a loop to end or not start. If one or more actions within the
> loop need to terminate further iterations, this should be done by setting
> the value of a tested variable, which could be the counter, if there is one
> and its final value isn't critical to later statements. Embedded break
> statements only confuse the debugging process.
> If one were to follow your logic, why not make everything a forever loop and
> break out whenever desired conditions are met?
> What you advocate, has very similar implications that other vomit-inducing
> practice of placing return statements anywhere other than at the end of a
> function, which is the only place they will ever belong. I wouldn't be
> surprised if you peddle that doctrine also.
> While it's unfortunate that you have clearly descended into common
> malpractices, it's no reason to have the temerity to accuse others of
> talking nonsense.[/color]
Quite frankly I find loops with explicit break conditions much easier to
understand then:
for (iCount=0; iCount<drpBox.length && !drpBox[iCount].value.match(regEx);
iCount++)
;
if( iCount != drpBox.length )
drpBox.selectedIndex = iCount;
Your example requires an additional test against the upper-boundary condition to
ensure that you aren't setting selectedIndex to the wrong thing. This means that
if you refactor the loop to use a variable other then iCount, you'll have to
watch out for side effects elsewhere in your code. It also means the scope of
the loop variable needs to be larger then it has to be to still be available
after the loop terminates.
Not to mention that ";" hanging out there, easily deleted by an inexperienced
programmer or missed when reading the source, turning your code into this:
for (iCount=0; iCount<drpBox.length && !drpBox[iCount].value.match(regEx);
iCount++)
if( iCount != drpBox.length )
drpBox.selectedIndex = iCount;
If early returns and break were not meant to be used in these ways, then they
wouldn't work in these ways. If every function/method _required_ a single entry
and exit point, then the (jit) compiler would enforce that requirement. The fact
that no C-based language has such a restriction indicates that early return and
break/continue are meant to be used the way they are used.
If he is "talking nonsense" then I guess O'Reilly and Sun are as well. There's a
whole discussion on this at <url:
http://www.gamedev.net/community/for...opic_id=208237 /> and the
general consensus is that if break/continue are good enough for K&R, they're
good enough for us. I know K&R used break liberally, I just can't find a Web
resource at the moment to demonstrate it.
--
| Grant Wagner <gwagner@agricoreunited.com>
* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html
* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp
* Netscape 6/7 DOM Reference available at:
*
http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
*
http://www.mozilla.org/docs/web-deve...upgrade_2.html 
