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

[jslint] Re: Filtered for...in

Expand Messages
  • Chris
    Hello, This seems like a reasonable suggestion. I can see the appeal of the alternative style proposed here. I see nothing unclear or obscure about the
    Message 1 of 19 , Nov 19, 2010
    • 0 Attachment
      Hello,

      This seems like a reasonable suggestion. I can see the appeal of the alternative style proposed here. I see nothing unclear or obscure about the "continue" keyword in this context. However, I remain unconvinced that JSLint would be better off permitting this.

      The "continue" and "break" keywords seem unclear if they occur at random points within a very large loop. A "continue" statement that is buried deep in the guts of its parent loop could indeed cause confusion. It could easily be overlooked by somebody looking over the code. Even if they find it, its meaning may not be clear: a reader might need to look back up the code to locate the loop's control statement. The situation can be further confounded by nested loops.

      Interestingly, the obscurity of purpose increases with the number of lines of code between the "continue" and the beginning of its parent loop. At the very top of the loop, the confusion caused by the "continue" statement is minimal.

      If I imagine a for..in loop that starts with a conditional block, and that conditional block contains "continue" as its only statement, then I would find that to be an acceptable level of complexity.

      Due to the nature of the problem, some increase in complexity is necessary. The current solution of wrapping the body of a for..in loop with a large conditional block also increases complexity.

      If I compare the increase in complexity caused by the current solution against the corresponding increase caused by the proposed solution, I don't see a significant difference. As others have pointed out, it seems to be a stylistic decision more than anything else.

      However, "continue" is a treacherous statement. It is maligned because of its similarity with "goto." Indeed, it is easy to imagine ways in which it could be abused. It has redeeming qualities when used correctly and consciously, but it could also lead to sloppy, confusing code if used poorly.

      Given the potential issues with "continue," I am not convinced that JSLint should suggest its use, particularly when the current solution functions perfectly well. I am happy to avoid use of "continue" unless it offers a clear improvement. I don't see such an improvement in this case.

      Furthermore, JSLint is in a unique position. There are many resources to help a beginning programmer learn JavaScript. There are, however, few resources to help a beginning programmer learn JavaScript WELL. Of those few, JSLint is the only tool of its kind that I am aware of. Many people look to JSLint and change their coding style because of it; in effect, improving themselves by drawing from Mr. Crockford's experience.

      Given the importance of JSLint, and the issues surrounding the "continue" statement, I opine that JSLint should not promote "continue" in any context.

      - Chris


      --- In jslint_com@yahoogroups.com, "Paul" <merlin@...> wrote:
      >
      > I agree with the OP.
      >
      > I use the continue statement in exactly the same manner and have trouble understanding the objection to responsible use of the continue statement.
      >
      > I just don't see where the continue statement can confuse logic where other flow control methods do not. I've personally gone nearly cross-eyed trying to deal with another developer's deep layers of nested flow control.
      >
      > I do see how the continue statement can be abused, but I'm sure we've all seen how if statements can also be abused. Which is why I think that outright discouraging its use altogether seems rather extreme.
      >
      > While I respect the difference in opinion, I'd also be glad to see an optional exception added for the unfiltered for..in check so that it could tolerate a single conditional statement block containing only "continue;" at the top of the loop's expression as a filter, but not tolerate for..in loops that are actually unfiltered.
    • Marcel Duran
      ... +1 -- Marcel Duran [Non-text portions of this message have been removed]
      Message 2 of 19 , Nov 19, 2010
      • 0 Attachment
        >
        > Given the importance of JSLint, and the issues surrounding the "continue"
        > statement, I opine that JSLint should not promote "continue" in any context.
        >
        > - Chris
        >
        +1

        --
        Marcel Duran


        [Non-text portions of this message have been removed]
      • abyssoft@ymail.com
        ... I too agree that it should not be encouraged. I m also a subscriber to the one exit point methodology/style as well. Multiple exit points tends to lead to
        Message 3 of 19 , Nov 21, 2010
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, Marcel Duran <contact@...> wrote:
          >
          > >
          > > Given the importance of JSLint, and the issues surrounding the "continue"
          > > statement, I opine that JSLint should not promote "continue" in any context.
          > >
          > > - Chris
          > >
          > +1
          >
          > --
          > Marcel Duran
          >
          >
          > [Non-text portions of this message have been removed]
          >

          I too agree that it should not be encouraged. I'm also a subscriber to the one exit point methodology/style as well. Multiple exit points tends to lead to spaghettification.
        • Erik Eckhardt
          *Edward*, You are right that votes don t make something right. It is also true that when we are talking in the area of style, the opinion of a great quantity
          Message 4 of 19 , Nov 21, 2010
          • 0 Attachment
            *Edward*,

            You are right that votes don't make something right. It is also true that
            when we are talking in the area of style, the opinion of a great quantity
            professionals (or at least nontrivial enthusiasts) is of some weight. And
            that you deleted your Stack Overflow account in late spring doesn't mean you
            are right, either. :)

            >> Since you are not wanting to exit the loop it would make more sense to
            plan around that condition where you do exit prematurely thereby negating
            the use of continue.

            This makes no sense. I don't want to *terminate* the loop (that would be
            "break"). I want to go to the next invocation/cycle/loop. Why should I plan
            around exiting prematurely when I don't want to do so?

            *Chris Nielsen*,

            >> Given the potential issues with "continue," I am not convinced that
            JSLint should suggest its use, particularly when the current solution
            functions perfectly well.

            I am completely with you about not *suggesting* the use of 'continue'. No
            one said anything about that. Instead, I asked for it to be *allowed*.

            Detecting that a 'continue' does in fact filter a for...in loop is far from
            promoting its use. The decision to not complain about continue was made on
            jslint some time ago. Until that decision is changed, why penalize for it?
            And if the decision IS changed, and the warning against the use of
            'continue' is given its own option to turn it off, we'd still be in the same
            position of getting an error about unfiltered for...in even though warnings
            on 'continue' have been suppressed. That means to me that jslint is broken.

            Filtering and the use of 'continue' are two completely separate issues. If
            someone doesn't like continue, great. But for cryin' out loud, it DOES
            filter a for...in loop!

            >> I am happy to avoid use of "continue" unless it offers a clear
            improvement. I don't see such an improvement in this case.

            If you wish to avoid it, more power to you. But you also said that you agree
            it's purely a stylistic consideration. Given that even though you don't
            personally see a clear improvement, I do see one, so what is the harm in
            allowing me my preference?

            Programmers sure are an opinionated bunch (not excluding self)!

            Erik

            On Fri, Nov 19, 2010 at 1:00 PM, Cheney, Edward A SSG RES USAR USARC <
            austin.cheney@...> wrote:

            >
            >
            > Erik,
            >
            >
            > > In my opinion this is little different than this greatly-upvoted Stack
            > > Overflow
            >
            > I deleted my Stack Overflow account in late spring. Popularity is not a
            > correlation to accuracy.
            >
            >
            > > The top 533 votes on the 3-most-upvoted answers all weigh in that they
            > > think the "one return per procedure" rule is, well, stupid.
            >
            > There is nothing wrong with multiple exit points from a container of
            > logic. If you have all that you need then destroy the current loop and
            > exit the current container as early as possible. This is the only way I
            > could make my markup beautification logic perform in an acceptable time
            > frame.
            >
            >
            > > I think this is one of those cases: I don't want to exit the loop, I
            > > don't want a huge if block polluting my function, I just want to
            > > quickly go to the next loop if the circumstances for this invocation
            > > are wrong.
            >
            > The point of the continue statement is to break the current index of a
            > loop provided a condition without breaking from the loop. Since you are
            > not wanting to exist the loop it would make more sense to plan around
            > that condition where you do exit prematurely thereby negating the use of
            > continue.
            >
            >
            > Austin Cheney, CISSP
            > http://prettydiff.com/
            >
            >


            [Non-text portions of this message have been removed]
          Your message has been successfully submitted and would be delivered to recipients shortly.