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

Re: [jslint] Re: Filtered for...in

Expand Messages
  • 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 1 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.