Loading ...
Sorry, an error occurred while loading the content.

continue

Expand Messages
  • Douglas Crockford
    I have received requests to warn on continue statements. How do you feel about that?
    Message 1 of 28 , Jun 17, 2009
    • 0 Attachment
      I have received requests to warn on continue statements.
      How do you feel about that?
    • mflanagan_swim
      As long as it s something I can also turn off, then fine. MJF
      Message 2 of 28 , Jun 17, 2009
      • 0 Attachment
        As long as it's something I can also turn off, then fine.

        MJF

        --- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
        >
        > I have received requests to warn on continue statements.
        > How do you feel about that?
        >
      • Michael Lorton
        Continue are glorified gotos, and therefore GenerallyConsideredHarmful. M. No-one should rent. Buy this house. ________________________________ From: Douglas
        Message 3 of 28 , Jun 17, 2009
        • 0 Attachment
          Continue are glorified gotos, and therefore GenerallyConsideredHarmful.

          M.

          No-one should rent. Buy this house.





          ________________________________
          From: Douglas Crockford <douglas@...>
          To: jslint_com@yahoogroups.com
          Sent: Wednesday, June 17, 2009 12:20:51 PM
          Subject: [jslint] continue

          I have received requests to warn on continue statements.
          How do you feel about that?



          ------------------------------------

          Yahoo! Groups Links



          [Non-text portions of this message have been removed]
        • jeddahbill
          Reply is below. ... Continue are glorified gotos, ... , are not switch ( ) { } statements as well?
          Message 4 of 28 , Jun 17, 2009
          • 0 Attachment
            Reply is below.

            --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
            >
            > Continue are glorified gotos, and therefore GenerallyConsideredHarmful.
            >
            > M.
            >
            > No-one should rent. Buy this house.
            >
            >
            >
            >
            >
            > ________________________________
            > From: Douglas Crockford <douglas@...>
            > To: jslint_com@yahoogroups.com
            > Sent: Wednesday, June 17, 2009 12:20:51 PM
            > Subject: [jslint] continue
            >
            > I have received requests to warn on continue statements.
            > How do you feel about that?
            >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            > [Non-text portions of this message have been removed]
            >
            "Continue are glorified gotos, ...", are not switch ( ) { } statements as well?
          • christian.wirkus
            ... I think so too, but what switch does is pretty obvious with one glance. Even if I don t use it, I don t hate finding it in someones code. I hate finding
            Message 5 of 28 , Jun 18, 2009
            • 0 Attachment
              > "Continue are glorified gotos, ...", are not switch ( ) { }
              > statements as well?

              I think so too, but what switch does is pretty obvious with one glance. Even if I don't use it, I don't hate finding it in someones code.
              I hate finding continue. And I hate missing it by accident.
            • mflanagan_swim
              I agree with switch being very useful, even though it is a glorified goto--it s *limited*, so pretty obvious and not very dangerous (ignoring fall-through
              Message 6 of 28 , Jun 18, 2009
              • 0 Attachment
                I agree with 'switch' being very useful, even though it is a glorified goto--it's *limited*, so pretty obvious and not very dangerous (ignoring fall-through w/o break, etc.).

                What about the 'break', though, when used in places similar to 'continue' (specifically, inside loops)? I prefer 'continue' to 'break', letting the loop condition handle whether we exit the loop. To me, 'continue' says, 'end this iteration and go back to loop control/condition'. I hate finding 'breaks' in loops, and I try to avoid them there. The 'break' in a loop is similar to a 'return' in the middle of a function. Again, not totally horrible, but something I shy away from.

                MJF

                --- In jslint_com@yahoogroups.com, "christian.wirkus" <christian.wirkus@...> wrote:
                >
                > > "Continue are glorified gotos, ...", are not switch ( ) { }
                > > statements as well?
                >
                > I think so too, but what switch does is pretty obvious with one glance. Even if I don't use it, I don't hate finding it in someones code.
                > I hate finding continue. And I hate missing it by accident.
                >
              • Michael Lorton
                Switches with fall-through are gotos, and therefore offenses against God and man. To get back on topic, does JSlint warn about missing breaks? M. Sent from my
                Message 7 of 28 , Jun 18, 2009
                • 0 Attachment
                  Switches with fall-through are gotos, and therefore offenses against God and man. To get back on topic, does JSlint warn about missing breaks?

                  M.

                  Sent from my iPhone

                  On Jun 18, 2009, at 7:29 AM, "christian.wirkus" <christian.wirkus@...> wrote:

                  "Continue are glorified gotos, ...", are not switch ( ) { }
                  statements as well?

                  I think so too, but what switch does is pretty obvious with one glance. Even if I don't use it, I don't hate finding it in someones code.
                  I hate finding continue. And I hate missing it by accident.


                  ------------------------------------

                  Yahoo! Groups Links
                • mbrrtt
                  Switches with fall-through are gotos, and therefore offenses against God and man. I don t agree. continue is useful in much the same circumstances as
                  Message 8 of 28 , Jun 18, 2009
                  • 0 Attachment
                    "Switches with fall-through are gotos, and therefore offenses against God and man."

                    I don't agree. "continue" is useful in much the same circumstances
                    as "break". The latter exits a "while" loop (or "for" loop or
                    "switch" statement) completely, while the former exits only the current iteration and proceeds to the next. But there is legitimate
                    code which is exceedingly awkward to rewrite without "continue" or
                    "break". This may occur when you have to write a large overall loop
                    with many conditions to be tested and processed inside. An
                    early condition being satisfied may lead to the completion of the
                    current iteration without testing subsequent conditions. "continue"
                    is a natural way to terminate the iteration. To rewrite the code
                    without using "continue," you would have to wrap all the remaining
                    code of the loop in an "else" statement. This may result in excessive
                    indentation and an "else" whose scope is most of the overall loop.
                    This does not promote readability and is not superior to the use of
                    "continue," IMHO.

                    This doesn't occur often, but it does occasionally. I have some
                    library code like this, and I see no ready way to improve it.


                    Of course a warning (rather than an error) is mostly harmless. But I
                    don't even agree that a warning should be issued, unless JSLint gets
                    very smart about when and how to rewrite code.
                  • Michael Lorton
                    People often say that: continue or break (or even goto) makes the code flow more naturally. Natural is a judgment call, but personally, I just don t see it.
                    Message 9 of 28 , Jun 18, 2009
                    • 0 Attachment
                      People often say that: continue or break (or even goto) makes the code flow more naturally. "Natural" is a judgment call, but personally, I just don't see it. I never use goto or anything like it (once in a while, I'll do a return from the middle of a function, but that's it). In maybe 15 years of abstaining, I have felt the lack.

                      M.

                      No-one should rent. Buy this house.





                      ________________________________
                      From: mbrrtt <mbrrtt@...>
                      To: jslint_com@yahoogroups.com
                      Sent: Thursday, June 18, 2009 12:02:11 PM
                      Subject: [jslint] Re: continue

                      "Switches with fall-through are gotos, and therefore offenses against God and man."

                      I don't agree. "continue" is useful in much the same circumstances
                      as "break". The latter exits a "while" loop (or "for" loop or
                      "switch" statement) completely, while the former exits only the current iteration and proceeds to the next. But there is legitimate
                      code which is exceedingly awkward to rewrite without "continue" or
                      "break". This may occur when you have to write a large overall loop
                      with many conditions to be tested and processed inside. An
                      early condition being satisfied may lead to the completion of the
                      current iteration without testing subsequent conditions. "continue"
                      is a natural way to terminate the iteration. To rewrite the code
                      without using "continue," you would have to wrap all the remaining
                      code of the loop in an "else" statement. This may result in excessive
                      indentation and an "else" whose scope is most of the overall loop.
                      This does not promote readability and is not superior to the use of
                      "continue," IMHO.

                      This doesn't occur often, but it does occasionally. I have some
                      library code like this, and I see no ready way to improve it.


                      Of course a warning (rather than an error) is mostly harmless. But I
                      don't even agree that a warning should be issued, unless JSLint gets
                      very smart about when and how to rewrite code.




                      ------------------------------------

                      Yahoo! Groups Links



                      [Non-text portions of this message have been removed]
                    • sandyhead25
                      Break is an early exit from a loop, while continue is only an early exit from an iteration. Unless you have a massive list of conditions to test during each
                      Message 10 of 28 , Jun 18, 2009
                      • 0 Attachment
                        Break is an early exit from a loop, while continue is only an early exit from an iteration. Unless you have a massive list of conditions to test during each iteration of a loop nothing is gained, from an execution perspective, by exiting the iteration early. There is dramatic efficiency gained by exiting a loop early.

                        Also break as a function value that does not exist for continue. When break is used to exit a loop early the value of the iterator becomes something that may not be the starting value or the ending value of the loop. That unknown value can be used to make logic decisions after the loop. Continue provides no such benefit.

                        As a result nothing is gained from using continue and by removing continue its containing logic can typically be removed as well so that you code becomes cleaner and more efficient to execute.

                        --- In jslint_com@yahoogroups.com, "mbrrtt" <mbrrtt@...> wrote:
                        >
                        > "Switches with fall-through are gotos, and therefore offenses against God and man."
                        >
                        > I don't agree. "continue" is useful in much the same circumstances
                        > as "break". The latter exits a "while" loop (or "for" loop or
                        > "switch" statement) completely, while the former exits only the current iteration and proceeds to the next. But there is legitimate
                        > code which is exceedingly awkward to rewrite without "continue" or
                        > "break". This may occur when you have to write a large overall loop
                        > with many conditions to be tested and processed inside. An
                        > early condition being satisfied may lead to the completion of the
                        > current iteration without testing subsequent conditions. "continue"
                        > is a natural way to terminate the iteration. To rewrite the code
                        > without using "continue," you would have to wrap all the remaining
                        > code of the loop in an "else" statement. This may result in excessive
                        > indentation and an "else" whose scope is most of the overall loop.
                        > This does not promote readability and is not superior to the use of
                        > "continue," IMHO.
                        >
                        > This doesn't occur often, but it does occasionally. I have some
                        > library code like this, and I see no ready way to improve it.
                        >
                        >
                        > Of course a warning (rather than an error) is mostly harmless. But I
                        > don't even agree that a warning should be issued, unless JSLint gets
                        > very smart about when and how to rewrite code.
                        >
                      • crlender
                        ... Efficiency doesn t even enter into this; it s all about code clarity. When you |break| from a loop, it s usually because you ve found what you were looking
                        Message 11 of 28 , Jun 18, 2009
                        • 0 Attachment
                          --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
                          >
                          > Break is an early exit from a loop, while continue is only an early
                          > exit from an iteration. Unless you have a massive list of
                          > conditions to test during each iteration of a loop nothing is
                          > gained, from an execution perspective, by exiting the iteration
                          > early. There is dramatic efficiency gained by exiting a loop early.

                          Efficiency doesn't even enter into this; it's all about code clarity.
                          When you |break| from a loop, it's usually because you've found what
                          you were looking for, and there's no need to continue looping.
                          |continue|, on the other hand, can be used to skip/filter iterations;
                          this is often necessary, and doing so at the beginning of the loop can
                          actually _increase_ readability. Take this very common example:

                          var children = document.getElementById("foo").childNodes;
                          for (var i = 0, len = children.length; i < len; i++) {
                          if (children[i].nodeType != 1) {
                          continue; // skip non-element nodes
                          }
                          // process child elements
                          }

                          This can be written without |continue|:

                          var children = document.getElementById("foo").childNodes;
                          for (var i = 0, len = children.length; i < len; i++) {
                          if (children[i].nodeType == 1) {
                          // process child elements
                          }
                          }

                          Does the same thing, but the main loop payload will have to be
                          indented by another 4 spaces. Now if we're looping over a larger
                          nested structure, the additional indentation will soon get in the
                          way of readability.

                          > As a result nothing is gained from using continue and by removing
                          > continue its containing logic can typically be removed as well so
                          > that you code becomes cleaner and more efficient to execute.

                          These supposed gains in efficiency will likely be minimal, if you can
                          even measure them, and are negligible compared to any calls to DOM
                          methods or properties. In any case, the suggested warnings about
                          |continue| are motivated by readability rather than performance, and
                          I dispute that continue will always make code less readable.

                          The comparison to |goto| is particularly ridiculous, IMHO. |break|,
                          which you appear to like, will jump to a label (!), whereas continue
                          will merely skip the rest of the iteration. And in case you weren't
                          aware, the JavaScript implementation in Firefox (SpiderMonkey) uses
                          |goto| quite a lot, as is usual in parsers and language
                          implementations. I'm not proposing |goto|s for JavaScript, but blindly
                          believing dogma will not make you a better programmer. Dijkstra's
                          seminal "GOTO considered harmful" article has also been disputed a
                          number of times (go look it up). If there's any procedural dogma
                          which has withstood the test of time, it's "know when to break the
                          rules".

                          To summarize, I very much disagree that |continue| is always harmful.
                          I have nothing against an option in JSLint to warn about its use, as
                          long as it's not mandatory.


                          - Conrad
                        • Nagy Endre
                          I think the break in most cases can be omitted.Ex. in the situation above, where is most frequently is used: for (i = 0; i
                          Message 12 of 28 , Jun 18, 2009
                          • 0 Attachment
                            I think the break in most cases can be omitted.Ex. in the situation above, where is most frequently is used:
                            for (i = 0; i < ar.length; i += 1){   some code here...   if (something){     break;   }   some other code...}
                            The loop can be rewritten as:var flag = true;var i = 0;while (flag && i < ar.length) {   some code...   if (something) {      flag = false; } else {    some code..    i += 1; }}
                            Basically is the same, but you clearly see the exit condition.
                            --- On Fri, 6/19/09, sandyhead25 <austin.cheney@...> wrote:

                            From: sandyhead25 <austin.cheney@...>
                            Subject: [jslint] Re: continue
                            To: jslint_com@yahoogroups.com
                            Date: Friday, June 19, 2009, 3:05 AM
























                            Break is an early exit from a loop, while continue is only an early exit from an iteration. Unless you have a massive list of conditions to test during each iteration of a loop nothing is gained, from an execution perspective, by exiting the iteration early. There is dramatic efficiency gained by exiting a loop early.



                            Also break as a function value that does not exist for continue. When break is used to exit a loop early the value of the iterator becomes something that may not be the starting value or the ending value of the loop. That unknown value can be used to make logic decisions after the loop. Continue provides no such benefit.



                            As a result nothing is gained from using continue and by removing continue its containing logic can typically be removed as well so that you code becomes cleaner and more efficient to execute.



                            --- In jslint_com@yahoogro ups.com, "mbrrtt" <mbrrtt@...> wrote:

                            >

                            > "Switches with fall-through are gotos, and therefore offenses against God and man."

                            >

                            > I don't agree. "continue" is useful in much the same circumstances

                            > as "break". The latter exits a "while" loop (or "for" loop or

                            > "switch" statement) completely, while the former exits only the current iteration and proceeds to the next. But there is legitimate

                            > code which is exceedingly awkward to rewrite without "continue" or

                            > "break". This may occur when you have to write a large overall loop

                            > with many conditions to be tested and processed inside. An

                            > early condition being satisfied may lead to the completion of the

                            > current iteration without testing subsequent conditions. "continue"

                            > is a natural way to terminate the iteration. To rewrite the code

                            > without using "continue," you would have to wrap all the remaining

                            > code of the loop in an "else" statement. This may result in excessive

                            > indentation and an "else" whose scope is most of the overall loop.

                            > This does not promote readability and is not superior to the use of

                            > "continue," IMHO.

                            >

                            > This doesn't occur often, but it does occasionally. I have some

                            > library code like this, and I see no ready way to improve it.

                            >

                            >

                            > Of course a warning (rather than an error) is mostly harmless. But I

                            > don't even agree that a warning should be issued, unless JSLint gets

                            > very smart about when and how to rewrite code.

                            >




































                            [Non-text portions of this message have been removed]
                          • Jean-Charles Meyrignac
                            ... As an old C/C++ coder, I have to say that this is terrible. First, I don t see how you can declare that it s much readable. You have more indentation, and
                            Message 13 of 28 , Jun 19, 2009
                            • 0 Attachment
                              On Fri, Jun 19, 2009 at 7:28 AM, Nagy Endre wrote:
                              >
                              > I think the break in most cases can be omitted.Ex. in the situation above, where is most frequently is used:
                              > for (i = 0; i < ar.length; i += 1){   some code here...   if (something){     break;   }   some other code...}
                              > The loop can be rewritten as:var flag = true;var i = 0;while (flag && i < ar.length) {   some code...   if (something) {      flag = false; } else {    some code..    i += 1; }}
                              > Basically is the same, but you clearly see the exit condition.
                              >
                              As an old C/C++ coder, I have to say that this is terrible.

                              First, I don't see how you can declare that it's much readable.
                              You have more indentation, and the condition for exiting the loop can
                              be buried deeply into your loop, or worse, the exit variable can be
                              set at several places, with tons of indentation, and the chance to
                              make a mistake increases a lot. And yes, I encountered bugs with such
                              a way of coding.

                              Secondly, you create a dummy variable used only once to check for a
                              condition, and this slightly degrades the speed of your code (I have
                              an example where a Javascript routine is called several thousands of
                              time, and such small difference counts, especially with slow JS
                              interpreters like IE).
                              When you code for performance in C, you must absolutely avoid this 'trick'.
                              I think that this technique is frequently used by people with only
                              theoretical knowledge (e.g. students), but in my opinion, it's bad
                              practice.

                              This makes me realize that it's generally a bad practice to declare a
                              variable for only one usage.

                              Long live to break/continue/switch !
                              From all my years of programming, I remember having only once used a
                              goto, since there were two imbricated loops, and exiting them would
                              have required to use two dummy variables to exit the loops. Using a
                              subroutine would have probably solved the problem more elegantly.

                              This reminds me of an old trick in C, where it's better to use
                              decrement than increment in loops.
                              for(i = 0;i<1000;++i)
                              can be replaced more efficiently by:
                              for(i=1000;i;--i)
                              In C, the resulting assembly code is a little bit faster.

                              JC
                            • Nagy Endre
                              Yes of course you re right. I just wanted to point that there is other solution too. For example at a php foreach loop you can t do it without a break
                              Message 14 of 28 , Jun 19, 2009
                              • 0 Attachment
                                Yes of course you're right. I just wanted to point that there is other solution too.
                                For example at a php foreach loop you can't do it without a break statement.

                                --- On Fri, 6/19/09, Jean-Charles Meyrignac <jcmeyrignac@...> wrote:

                                From: Jean-Charles Meyrignac <jcmeyrignac@...>
                                Subject: Re: [jslint] Re: continue
                                To: jslint_com@yahoogroups.com
                                Date: Friday, June 19, 2009, 11:01 AM

















                                On Fri, Jun 19, 2009 at 7:28 AM, Nagy Endre wrote:

                                >

                                > I think the break in most cases can be omitted.Ex. in the situation above, where is most frequently is used:

                                > for (i = 0; i < ar.length; i += 1){   some code here...   if (something){     break;   }   some other code...}

                                > The loop can be rewritten as:var flag = true;var i = 0;while (flag && i < ar.length) {   some code...   if (something) {      flag = false; } else {    some code..    i += 1; }}

                                > Basically is the same, but you clearly see the exit condition.

                                >

                                As an old C/C++ coder, I have to say that this is terrible.



                                First, I don't see how you can declare that it's much readable.

                                You have more indentation, and the condition for exiting the loop can

                                be buried deeply into your loop, or worse, the exit variable can be

                                set at several places, with tons of indentation, and the chance to

                                make a mistake increases a lot. And yes, I encountered bugs with such

                                a way of coding.



                                Secondly, you create a dummy variable used only once to check for a

                                condition, and this slightly degrades the speed of your code (I have

                                an example where a Javascript routine is called several thousands of

                                time, and such small difference counts, especially with slow JS

                                interpreters like IE).

                                When you code for performance in C, you must absolutely avoid this 'trick'.

                                I think that this technique is frequently used by people with only

                                theoretical knowledge (e.g. students), but in my opinion, it's bad

                                practice.



                                This makes me realize that it's generally a bad practice to declare a

                                variable for only one usage.



                                Long live to break/continue/ switch !

                                From all my years of programming, I remember having only once used a

                                goto, since there were two imbricated loops, and exiting them would

                                have required to use two dummy variables to exit the loops. Using a

                                subroutine would have probably solved the problem more elegantly.



                                This reminds me of an old trick in C, where it's better to use

                                decrement than increment in loops.

                                for(i = 0;i<1000;++i)

                                can be replaced more efficiently by:

                                for(i=1000;i; --i)

                                In C, the resulting assembly code is a little bit faster.



                                JC





























                                [Non-text portions of this message have been removed]
                              • Marcel Duran
                                What about break with labels? var i, j; outer: for (i = 0; i 10) { break outer; } } }
                                Message 15 of 28 , Jun 19, 2009
                                • 0 Attachment
                                  What about break with labels?
                                  var i, j;

                                  outer:
                                  for (i = 0; i < 5; i += 1) {
                                  inner:
                                  for (j = 0; j < 5; j += 1) {
                                  if (i * j > 10) {
                                  break outer;
                                  }
                                  }
                                  }

                                  window.alert(i);
                                  window.alert(j);

                                  In this case, I want to get the first 2 numbers i, j where i * j is greater
                                  than 10 after the loops which are 3 and 4 respectively. It's sometimes
                                  useful using that way. I myself used it once iterating the styleSheets on a
                                  page on the outer loop and the cssRules on the inner loop looking for a
                                  given selectorText, once found, just set a given style property with a given
                                  value then break all loops using break with the outer label, avoiding
                                  unnecessary iterations on the remaining rules/stylesheets.

                                  BTW, JSLint doesn't complain about unused labels, the "inner:" label on the
                                  code above is not used at all. Shouldn't that be warned?

                                  --
                                  Marcel Duran


                                  [Non-text portions of this message have been removed]
                                • sandyhead25
                                  ... Why are people complaining about indentation? JavaScript code should be minified in production.
                                  Message 16 of 28 , Jun 20, 2009
                                  • 0 Attachment
                                    --- In jslint_com@yahoogroups.com, Jean-Charles Meyrignac <jcmeyrignac@...> wrote:
                                    >
                                    > On Fri, Jun 19, 2009 at 7:28 AM, Nagy Endre wrote:
                                    > >
                                    > > I think the break in most cases can be omitted.Ex. in the situation above, where is most frequently is used:
                                    > > for (i = 0; i < ar.length; i += 1){   some code here...   if (something){     break;   }   some other code...}
                                    > > The loop can be rewritten as:var flag = true;var i = 0;while (flag && i < ar.length) {   some code...   if (something) {      flag = false; } else {    some code..    i += 1; }}
                                    > > Basically is the same, but you clearly see the exit condition.
                                    > >
                                    > As an old C/C++ coder, I have to say that this is terrible.
                                    >
                                    > First, I don't see how you can declare that it's much readable.
                                    > You have more indentation, and the condition for exiting the loop can
                                    > be buried deeply into your loop, or worse, the exit variable can be
                                    > set at several places, with tons of indentation, and the chance to
                                    > make a mistake increases a lot. And yes, I encountered bugs with such
                                    > a way of coding.
                                    >
                                    > Secondly, you create a dummy variable used only once to check for a
                                    > condition, and this slightly degrades the speed of your code (I have
                                    > an example where a Javascript routine is called several thousands of
                                    > time, and such small difference counts, especially with slow JS
                                    > interpreters like IE).
                                    > When you code for performance in C, you must absolutely avoid this 'trick'.
                                    > I think that this technique is frequently used by people with only
                                    > theoretical knowledge (e.g. students), but in my opinion, it's bad
                                    > practice.
                                    >
                                    > This makes me realize that it's generally a bad practice to declare a
                                    > variable for only one usage.
                                    >
                                    > Long live to break/continue/switch !
                                    > From all my years of programming, I remember having only once used a
                                    > goto, since there were two imbricated loops, and exiting them would
                                    > have required to use two dummy variables to exit the loops. Using a
                                    > subroutine would have probably solved the problem more elegantly.
                                    >
                                    > This reminds me of an old trick in C, where it's better to use
                                    > decrement than increment in loops.
                                    > for(i = 0;i<1000;++i)
                                    > can be replaced more efficiently by:
                                    > for(i=1000;i;--i)
                                    > In C, the resulting assembly code is a little bit faster.
                                    >
                                    > JC
                                    >

                                    Why are people complaining about indentation? JavaScript code should be minified in production.
                                  • crlender
                                    ... And C code will be compiled before use. That doesn t make source code with very long lines any easier to read. Excessive nesting is also know as the Arrow
                                    Message 17 of 28 , Jun 20, 2009
                                    • 0 Attachment
                                      --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
                                      > Why are people complaining about indentation? JavaScript code
                                      > should be minified in production.

                                      And C code will be compiled before use. That doesn't make source code
                                      with very long lines any easier to read. Excessive nesting is also
                                      know as the "Arrow Anti Pattern" or "Dangerously Deep Nesting".
                                      Granted, the times where lines of code had to be less than 80
                                      characters wide are in the past, and languages with verbose identifier
                                      names (like Java or JavaScript) can profit from longer lines, but
                                      most people still voluntarily use conventions to limit line length.

                                      I see from your code that you don't have a problem with lines with 1k
                                      characters or more (the longest line in your prettyprint.js is 1287
                                      characters). I find code like that horribly hard to read. I often
                                      edit more than one file simultaneously, or same file split vertically
                                      in two editor sub-windows, and I use side-by-side diffs all the time.
                                      With lots of indentation, you'll constantly be scrolling horizontally
                                      in order to see the actual code. You could tell the editor to wrap
                                      long lines, but I wouldn't call that a good idea in a language where
                                      line breaks can be significant - like JavaScript.

                                      So-called "guard clauses" can be used to avoid the arrow shape and
                                      make code more readable, and |continue| is a very effective statement
                                      in guard clauses.


                                      - Conrad
                                    • sandyhead25
                                      ... If indentation becomes that big a problem that you can no longer read your code you can either make design decisions more conservatively, reduce the size
                                      Message 18 of 28 , Jun 20, 2009
                                      • 0 Attachment
                                        > And C code will be compiled before use. That doesn't make source code
                                        > with very long lines any easier to read. Excessive nesting is also
                                        > know as the "Arrow Anti Pattern" or "Dangerously Deep Nesting".
                                        > Granted, the times where lines of code had to be less than 80
                                        > characters wide are in the past, and languages with verbose identifier
                                        > names (like Java or JavaScript) can profit from longer lines, but
                                        > most people still voluntarily use conventions to limit line length.

                                        If indentation becomes that big a problem that you can no longer read your code you can either make design decisions more conservatively, reduce the size of your indentation, or using a wider resolution.

                                        > I see from your code that you don't have a problem with lines with 1k
                                        > characters or more (the longest line in your prettyprint.js is 1287
                                        > characters). I find code like that horribly hard to read.

                                        Its a string literal representing CSS code. I have no plans on changing that code. I could break it into many small fragments to reduce the amount of scrolling that I will not be doing.

                                        > I often
                                        > edit more than one file simultaneously, or same file split vertically
                                        > in two editor sub-windows, and I use side-by-side diffs all the time.
                                        > With lots of indentation, you'll constantly be scrolling horizontally
                                        > in order to see the actual code. You could tell the editor to wrap
                                        > long lines, but I wouldn't call that a good idea in a language where
                                        > line breaks can be significant - like JavaScript.
                                        >
                                        > So-called "guard clauses" can be used to avoid the arrow shape and
                                        > make code more readable, and |continue| is a very effective statement
                                        > in guard clauses.
                                        >
                                        >
                                        > - Conrad
                                        >
                                      • Michael Lorton
                                        ... The problem with excessive nesting is not (or not primarily) that it is difficult to read. The problem is that it is difficult to understand. In formal
                                        Message 19 of 28 , Jun 20, 2009
                                        • 0 Attachment
                                          crlender <crlender@gm...> writes:

                                          >--- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
                                          >> Why are people complaining about indentation? JavaScript code
                                          >> should be minified in production.

                                          > And C code will be compiled before use. That doesn't make source code
                                          > with very long lines any easier to read. Excessive nesting is also know as
                                          > the "Arrow Anti Pattern" or "Dangerously Deep Nesting".

                                          The problem with excessive nesting is not (or not primarily) that it is difficult to read. The problem is that it is difficult to understand. In formal terms, it has high cyclomatic complexity. There are many paths through the function, meaning there are many possible ways to screw it up.

                                          The "continue" statement does NOT solve this problem, any more than taking out all the indentation would solve the problem. All it does it conceal the problem from the person writing the code; it certainly doesn't conceal the problem from the person trying to READ the code.

                                          At least excessive indentation give the reader a certain assistance in visually entangling a cyclomaticly complex function. You can look at a statement indented five tabs over and reason, "Hmmm, to get here, I've survived a bunch of 'if' statements." With "continue", "break", and "return" you have to scan backward to the start of the function looking for them to see why you may not get to a certain line.

                                          (In a futile attempt to wrest this thread back on to topic, I want to suggest that JSLint optionally generate warnings for "continue", "break", and "return", and that option be turning by default, at least for the first two.)

                                          M.

                                          No-one should rent. Buy this house.

                                          [Non-text portions of this message have been removed]
                                        • crlender
                                          ... There s a difference for you? ... If you start reading a function at a |break| statement in the middle, yeah, you will have to backtrack to the top to know
                                          Message 20 of 28 , Jun 20, 2009
                                          • 0 Attachment
                                            --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
                                            >
                                            > crlender <crlender@gm...> writes:
                                            >
                                            > >--- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@> wrote:
                                            > >> Why are people complaining about indentation? JavaScript code
                                            > >> should be minified in production.
                                            >
                                            > > And C code will be compiled before use. That doesn't make source code
                                            > > with very long lines any easier to read. Excessive nesting is also know as
                                            > > the "Arrow Anti Pattern" or "Dangerously Deep Nesting".
                                            >
                                            > The problem with excessive nesting is not (or not primarily) that
                                            > it is difficult to read. The problem is that it is difficult to
                                            > understand.

                                            There's a difference for you?

                                            > At least excessive indentation give the reader a certain assistance
                                            > in visually entangling a cyclomaticly complex function. You can
                                            > look at a statement indented five tabs over and reason, "Hmmm, to
                                            > get here, I've survived a bunch of 'if' statements." With
                                            > "continue", "break", and "return" you have to scan backward to the
                                            > start of the function looking for them to see why you may not get
                                            > to a certain line.

                                            If you start reading a function at a |break| statement in the middle,
                                            yeah, you will have to backtrack to the top to know what's going
                                            on. If you start reading the function from the top, on the other
                                            hand, you could immediately see that the 5-layer-deep |if| nest will
                                            never be reached in some cases, because the rest of the loop was cut
                                            short by a filter. I accept that it's a question of personal
                                            preference which style you prefer, and I can understand the reasoning
                                            behind the "single point of exit" style. What I was originally
                                            objecting against was the dogmatic overreaction of putting |continue|
                                            in the same league as |goto|, and the imaginary performance
                                            improvements. Like everything else, it can be overused and abused,
                                            but that's not a reason to unconditionally call it "evil".

                                            > (In a futile attempt to wrest this thread back on to topic, I want
                                            > to suggest that JSLint optionally generate warnings for "continue",
                                            > "break", and "return", and that option be turning by default, at
                                            > least for the first two.)

                                            As I said, as long as it's an option, I'm okay with it. I don't think
                                            it should be turned on by default, but if that makes you happy, it's
                                            fine by me.


                                            - Conrad
                                          • Randall Lee Spence
                                            ... to suggest that JSLint optionally generate warnings for continue , break , and return , and that option be turning by default, at least for the first
                                            Message 21 of 28 , Jun 20, 2009
                                            • 0 Attachment
                                              --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
                                              >
                                              > crlender <crlender@gm...> writes:
                                              >
                                              > >--- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@> wrote:
                                              > >> Why are people complaining about indentation? JavaScript code
                                              > >> should be minified in production.
                                              >
                                              > > And C code will be compiled before use. That doesn't make source code
                                              > > with very long lines any easier to read. Excessive nesting is also know as
                                              > > the "Arrow Anti Pattern" or "Dangerously Deep Nesting".
                                              >
                                              > The problem with excessive nesting is not (or not primarily) that it is difficult to read. The problem is that it is difficult to understand. In formal terms, it has high cyclomatic complexity. There are many paths through the function, meaning there are many possible ways to screw it up.
                                              >
                                              > The "continue" statement does NOT solve this problem, any more than taking out all the indentation would solve the problem. All it does it conceal the problem from the person writing the code; it certainly doesn't conceal the problem from the person trying to READ the code.
                                              >
                                              > At least excessive indentation give the reader a certain assistance in visually entangling a cyclomaticly complex function. You can look at a statement indented five tabs over and reason, "Hmmm, to get here, I've survived a bunch of 'if' statements." With "continue", "break", and "return" you have to scan backward to the start of the function looking for them to see why you may not get to a certain line.
                                              >
                                              > (In a futile attempt to wrest this thread back on to topic, I want
                                              to suggest that JSLint optionally generate warnings for "continue", "break", and "return", and that option be turning by default, at least for the first two.)
                                              >
                                              > M.
                                              >
                                              > No-one should rent. Buy this house.
                                              >
                                              > [Non-text portions of this message have been removed]
                                              >

                                              I agree that a warning regarding the use of the continue statement is
                                              a good addition to JSLint. As Douglas says in his book "I have never
                                              seen a piece of code that was not improved by refactoring it to
                                              remove the continue statement."

                                              I do not agree with throwing a warning for break or return, and I
                                              won't go into detail as to why since that has been covered
                                              extensively already. I'm just throwing my two cents in for what it is
                                              worth, which may actually only be two cents.

                                              Randall
                                            • Michael Lorton
                                              Since everyone asked, here is my personal Scale of Evil Control Structures, from most to least: goto -- so evil, you probably shouldn t even use a language
                                              Message 22 of 28 , Jun 20, 2009
                                              • 0 Attachment
                                                Since everyone asked, here is my personal Scale of Evil Control Structures, from most to least:

                                                goto -- so evil, you probably shouldn't even use a language that has it.
                                                break, continue -- mmm, kinda evil. If you have a very, very good reason, use it. Once.
                                                return -- OK, if you're right at the top of the function and you have to quit early because of bad parameters or bad state or something
                                                while -- Fine, just be careful of infinite loops.
                                                if -- Good
                                                for -- Better than while, maybe a little clunky
                                                each -- Good (not the JS foreach, which is a little broken, but JQuery-style each or Java's iterated for)
                                                function -- Perfect

                                                I've always thought of break and continue as pretty much equals on the Scale of Evil Control Structures but others feel differently.

                                                M.



                                                No-one should rent. Buy this house.





                                                ________________________________
                                                From: Randall Lee Spence <analogueweb@...>
                                                To: jslint_com@yahoogroups.com
                                                Sent: Saturday, June 20, 2009 8:56:02 AM
                                                Subject: [jslint] Re: continue

                                                --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
                                                >
                                                > crlender <crlender@gm...> writes:
                                                >
                                                > >--- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@> wrote:
                                                > >> Why are people complaining about indentation? JavaScript code
                                                > >> should be minified in production.
                                                >
                                                > > And C code will be compiled before use. That doesn't make source code
                                                > > with very long lines any easier to read. Excessive nesting is also know as
                                                > > the "Arrow Anti Pattern" or "Dangerously Deep Nesting".
                                                >
                                                > The problem with excessive nesting is not (or not primarily) that it is difficult to read. The problem is that it is difficult to understand. In formal terms, it has high cyclomatic complexity. There are many paths through the function, meaning there are many possible ways to screw it up.
                                                >
                                                > The "continue" statement does NOT solve this problem, any more than taking out all the indentation would solve the problem. All it does it conceal the problem from the person writing the code; it certainly doesn't conceal the problem from the person trying to READ the code.
                                                >
                                                > At least excessive indentation give the reader a certain assistance in visually entangling a cyclomaticly complex function. You can look at a statement indented five tabs over and reason, "Hmmm, to get here, I've survived a bunch of 'if' statements." With "continue", "break", and "return" you have to scan backward to the start of the function looking for them to see why you may not get to a certain line.
                                                >
                                                > (In a futile attempt to wrest this thread back on to topic, I want
                                                to suggest that JSLint optionally generate warnings for "continue", "break", and "return", and that option be turning by default, at least for the first two.)
                                                >
                                                > M.
                                                >
                                                > No-one should rent. Buy this house.
                                                >
                                                > [Non-text portions of this message have been removed]
                                                >

                                                I agree that a warning regarding the use of the continue statement is
                                                a good addition to JSLint. As Douglas says in his book "I have never
                                                seen a piece of code that was not improved by refactoring it to
                                                remove the continue statement."

                                                I do not agree with throwing a warning for break or return, and I
                                                won't go into detail as to why since that has been covered
                                                extensively already. I'm just throwing my two cents in for what it is
                                                worth, which may actually only be two cents.

                                                Randall




                                                ------------------------------------

                                                Yahoo! Groups Links



                                                [Non-text portions of this message have been removed]
                                              • sandyhead25
                                                ... Break is not evil. It forces early return from a loop, which results in a value for the iterator that is neither the start or end value of the loop. That
                                                Message 23 of 28 , Jun 20, 2009
                                                • 0 Attachment
                                                  --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
                                                  >
                                                  > Since everyone asked, here is my personal Scale of Evil Control Structures, from most to least:
                                                  >
                                                  > goto -- so evil, you probably shouldn't even use a language that has it.
                                                  > break, continue -- mmm, kinda evil. If you have a very, very good reason, use it. Once.
                                                  > return -- OK, if you're right at the top of the function and you have to quit early because of bad parameters or bad state or something
                                                  > while -- Fine, just be careful of infinite loops.
                                                  > if -- Good
                                                  > for -- Better than while, maybe a little clunky
                                                  > each -- Good (not the JS foreach, which is a little broken, but JQuery-style each or Java's iterated for)
                                                  > function -- Perfect
                                                  >

                                                  Break is not evil. It forces early return from a loop, which results in a value for the iterator that is neither the start or end value of the loop. That is useful for making decisions about positions of points in a group. This sort of logic is necessary.

                                                  Return forces and early return from a function. This not only increases efficency by warding off undesired execution, but also impacts the values of closures. That sort of logic is very similar to the example mentioned above and is absolutely necessary.

                                                  To solve everybody else's whining with regard to understandability versus indentation proper code should be broken into as many small functions as possible to eliminate restatement. This sort of design is vital for taking advantage of simplistic unit testing. That sort of design also eliminates confusion with regard to condition complexity.
                                                • Randall Lee Spence
                                                  ... I am sure that if this topic is debated long enough, almost every statement or method will have someone calling it evil or declaring its use as counter
                                                  Message 24 of 28 , Jun 20, 2009
                                                  • 0 Attachment
                                                    --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@...> wrote:
                                                    >
                                                    > --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@> wrote:
                                                    > >
                                                    > > Since everyone asked, here is my personal Scale of Evil Control Structures, from most to least:
                                                    > >
                                                    > > goto -- so evil, you probably shouldn't even use a language that has it.
                                                    > > break, continue -- mmm, kinda evil. If you have a very, very good reason, use it. Once.
                                                    > > return -- OK, if you're right at the top of the function and you have to quit early because of bad parameters or bad state or something
                                                    > > while -- Fine, just be careful of infinite loops.
                                                    > > if -- Good
                                                    > > for -- Better than while, maybe a little clunky
                                                    > > each -- Good (not the JS foreach, which is a little broken, but JQuery-style each or Java's iterated for)
                                                    > > function -- Perfect
                                                    > >
                                                    >
                                                    > Break is not evil. It forces early return from a loop, which results in a value for the iterator that is neither the start or end value of the loop. That is useful for making decisions about positions of points in a group. This sort of logic is necessary.
                                                    >
                                                    > Return forces and early return from a function. This not only increases efficency by warding off undesired execution, but also impacts the values of closures. That sort of logic is very similar to the example mentioned above and is absolutely necessary.
                                                    >
                                                    > To solve everybody else's whining with regard to understandability versus indentation proper code should be broken into as many small functions as possible to eliminate restatement. This sort of design is vital for taking advantage of simplistic unit testing. That sort of design also eliminates confusion with regard to condition complexity.
                                                    >

                                                    I am sure that if this topic is debated long enough, almost every
                                                    statement or method will have someone calling it evil or declaring
                                                    its use as counter intuitive. But at what point do we stop? If we
                                                    warn about breaks, returns, continues and switches, what's to stop us
                                                    from eliminating for loops and if statements since they can also be
                                                    misused and abused? Eventually we will be left with only empty
                                                    function statements, and I am sure someone would have a perfectly
                                                    valid complaint about that.

                                                    I supposed it would be much easier to write JavaScript if that were
                                                    the case:

                                                    var doNothing = function () {
                                                    //Success!;
                                                    }

                                                    Randall
                                                  • jeddahbill
                                                    ... Good one, Randall! Dittos!
                                                    Message 25 of 28 , Jun 20, 2009
                                                    • 0 Attachment
                                                      --- In jslint_com@yahoogroups.com, "Randall Lee Spence" <analogueweb@...> wrote:
                                                      >
                                                      > --- In jslint_com@yahoogroups.com, "sandyhead25" <austin.cheney@> wrote:
                                                      > >
                                                      > > --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@> wrote:
                                                      > > >
                                                      > > > Since everyone asked, here is my personal Scale of Evil Control Structures, from most to least:
                                                      > > >
                                                      > > > goto -- so evil, you probably shouldn't even use a language that has it.
                                                      > > > break, continue -- mmm, kinda evil. If you have a very, very good reason, use it. Once.
                                                      > > > return -- OK, if you're right at the top of the function and you have to quit early because of bad parameters or bad state or something
                                                      > > > while -- Fine, just be careful of infinite loops.
                                                      > > > if -- Good
                                                      > > > for -- Better than while, maybe a little clunky
                                                      > > > each -- Good (not the JS foreach, which is a little broken, but JQuery-style each or Java's iterated for)
                                                      > > > function -- Perfect
                                                      > > >
                                                      > >
                                                      > > Break is not evil. It forces early return from a loop, which results in a value for the iterator that is neither the start or end value of the loop. That is useful for making decisions about positions of points in a group. This sort of logic is necessary.
                                                      > >
                                                      > > Return forces and early return from a function. This not only increases efficency by warding off undesired execution, but also impacts the values of closures. That sort of logic is very similar to the example mentioned above and is absolutely necessary.
                                                      > >
                                                      > > To solve everybody else's whining with regard to understandability versus indentation proper code should be broken into as many small functions as possible to eliminate restatement. This sort of design is vital for taking advantage of simplistic unit testing. That sort of design also eliminates confusion with regard to condition complexity.
                                                      > >
                                                      >
                                                      > I am sure that if this topic is debated long enough, almost every
                                                      > statement or method will have someone calling it evil or declaring
                                                      > its use as counter intuitive. But at what point do we stop? If we
                                                      > warn about breaks, returns, continues and switches, what's to stop us
                                                      > from eliminating for loops and if statements since they can also be
                                                      > misused and abused? Eventually we will be left with only empty
                                                      > function statements, and I am sure someone would have a perfectly
                                                      > valid complaint about that.
                                                      >
                                                      > I supposed it would be much easier to write JavaScript if that were
                                                      > the case:
                                                      >
                                                      > var doNothing = function () {
                                                      > //Success!;
                                                      > }
                                                      >
                                                      > Randall
                                                      >
                                                      Good one, Randall! Dittos!
                                                    • Jean-Charles Meyrignac
                                                      ... You forgot while , which can be replaced by for. ... Sorry, but it doesn t pass JsLint: Problem at line 3 character 2: Missing semicolon. JC
                                                      Message 26 of 28 , Jun 20, 2009
                                                      • 0 Attachment
                                                        On Sat, Jun 20, 2009 at 10:47 PM, Randall Lee Spence wrote:
                                                        >
                                                        > But at what point do we stop? If we
                                                        > warn about breaks, returns, continues and switches, what's to stop us
                                                        > from eliminating for loops and if statements since they can also be
                                                        > misused and abused?

                                                        You forgot 'while', which can be replaced by for.

                                                        > I supposed it would be much easier to write JavaScript if that were
                                                        > the case:
                                                        >
                                                        > var doNothing = function () {
                                                        > //Success!;
                                                        > }
                                                        >
                                                        Sorry, but it doesn't pass JsLint:
                                                        Problem at line 3 character 2: Missing semicolon.

                                                        JC
                                                      • Michael Lorton
                                                        ... How is that a good one? Yes, nothing on this earth is perfectly good and few things are perfectly evil, but we still have the daily task of figuring out
                                                        Message 27 of 28 , Jun 20, 2009
                                                        • 0 Attachment
                                                          >> I am sure that if this topic is debated long enough, almost every
                                                          >> statement or method will have someone calling it evil or declaring
                                                          >> its use as counter intuitive. But at what point do we stop? If we
                                                          >> warn about breaks, returns, continues and switches, what's to stop us
                                                          >> from eliminating for loops and if statements since they can also be
                                                          >> misused and abused? Eventually we will be left with only empty
                                                          >> function statements, and I am sure someone would have a perfectly
                                                          >> valid complaint about that.
                                                          >>
                                                          >> I supposed it would be much easier to write JavaScript if that were
                                                          >> the case:
                                                          >>
                                                          >> var doNothing = function () {
                                                          >> //Success!;
                                                          >> }
                                                          >>
                                                          >> Randall
                                                          >>
                                                          >Good one, Randall! Dittos!

                                                          How is that a good one? Yes, nothing on this earth is perfectly good and few things are perfectly evil, but we still have the daily task of figuring out what to do, and reductionist sarcasm like "well, anything can be misused" doesn't help at all.

                                                          > Jean-Charles Meyrignac <jcmeyrignac@gm...> writes:

                                                          > Sorry, but it doesn't pass JsLint:
                                                          > Problem at line 3 character 2: Missing semicolon.

                                                          Now *that* is a good one.

                                                          M.

                                                          [Non-text portions of this message have been removed]
                                                        • Randall Lee Spence
                                                          ... I agree Michael, that was a good one! Reductionist sarcasm aside, I d like to state again that I do agree with JSLint throwing a warning on continue, I
                                                          Message 28 of 28 , Jun 20, 2009
                                                          • 0 Attachment
                                                            --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
                                                            >
                                                            > >> I am sure that if this topic is debated long enough, almost every
                                                            > >> statement or method will have someone calling it evil or declaring
                                                            > >> its use as counter intuitive. But at what point do we stop? If we
                                                            > >> warn about breaks, returns, continues and switches, what's to stop us
                                                            > >> from eliminating for loops and if statements since they can also be
                                                            > >> misused and abused? Eventually we will be left with only empty
                                                            > >> function statements, and I am sure someone would have a perfectly
                                                            > >> valid complaint about that.
                                                            > >>
                                                            > >> I supposed it would be much easier to write JavaScript if that were
                                                            > >> the case:
                                                            > >>
                                                            > >> var doNothing = function () {
                                                            > >> //Success!;
                                                            > >> }
                                                            > >>
                                                            > >> Randall
                                                            > >>
                                                            > >Good one, Randall! Dittos!
                                                            >
                                                            > How is that a good one? Yes, nothing on this earth is perfectly good and few things are perfectly evil, but we still have the daily task of figuring out what to do, and reductionist sarcasm like "well, anything can be misused" doesn't help at all.
                                                            >
                                                            > > Jean-Charles Meyrignac <jcmeyrignac@gm...> writes:
                                                            >
                                                            > > Sorry, but it doesn't pass JsLint:
                                                            > > Problem at line 3 character 2: Missing semicolon.
                                                            >
                                                            > Now *that* is a good one.
                                                            >
                                                            > M.
                                                            >
                                                            > [Non-text portions of this message have been removed]
                                                            >

                                                            I agree Michael, that was a good one!

                                                            Reductionist sarcasm aside, I'd like to state again that I do agree
                                                            with JSLint throwing a warning on continue, I just don't agree with
                                                            throwing a warning on break or return. Since the original post was
                                                            about continue, and it seems as if enough people have agreed it would
                                                            make a good addition, I suspect we will this as an option in the next
                                                            version of JSLint.

                                                            As I was re-reading the thread I noticed you asked if JSlint warned
                                                            about missing breaks in switch statements, but I didn't see where
                                                            anyone addressed that directly. You may have already found the answer
                                                            on your own, but in case you didn't, and for the benefit of others,
                                                            it does. JSLint expects that the statement before the next case or
                                                            default is either a break, return or throw.

                                                            Randall
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.