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

Re: Filtered for...in

Expand Messages
  • Douglas Crockford
    ... I do not recommend use of continue. JSLint currently barely tolerates it.
    Message 1 of 19 , Nov 17, 2010
    • 0 Attachment
      --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
      >
      > JSLint is complaining that my for...in loop is not filtered. The docs
      > suggest the following format:
      >
      > for (name in obj) {
      > if (obj.hasOwnProperty(name)) {
      > ...
      > }
      > }
      >
      > But I am filtering my for in loops, just slightly differently:
      >
      > for (name in obj) {
      > if (!obj.hasOwnProperty(name)) {continue;}
      > ...
      > }
      >
      > I like this because it avoids an extra level of indentation in my code. If I
      > want to add or remove this line it can be done in just a single place
      > instead of at the top and bottom of the loop.

      I do not recommend use of continue. JSLint currently barely tolerates it.
    • Michael Mikowski
      In my team code standards, continue and break are only to be used with a label. This is similar to other Best Practice conventions in other languages because
      Message 2 of 19 , Nov 17, 2010
      • 0 Attachment
        In my team code standards, continue and break are only to be used with a label.
        This is similar to other Best Practice conventions in other languages because
        it avoids the ambiguity of the continue or break statement. And sometimes, its
        actually quite useful (e.g. break of an outer loop from an inner loop when a
        condition is met).

        Here is a contrived example:

        var
        str_search_model = 'Ford Escort',
        hash_obj_car = {
        escort : { str_model : 'Ford Escort' },
        malibu : { str_model: 'Chevy Malibu'}
        },
        obj_car,
        str_key
        ;

        FIND_CAR:
        for ( str_key in hash_car ){
        if ( ! hash_obj_car.hasOwnProperty(str_name)){ continue FIND_CAR; }
        obj_car = hash_obj_car[str_key];
        if ( obj_car.str_model === str_search_model ){ break FIND_CAR; }
        }

        // and now obj_car is the 'Ford Escort' model, or if not found, undefined






        ________________________________
        From: Douglas Crockford <douglas@...>
        To: jslint_com@yahoogroups.com
        Sent: Wed, November 17, 2010 10:02:35 AM
        Subject: [jslint] Re: Filtered for...in


        --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
        >
        > JSLint is complaining that my for...in loop is not filtered. The docs
        > suggest the following format:
        >
        > for (name in obj) {
        > if (obj.hasOwnProperty(name)) {
        > ...
        > }
        > }
        >
        > But I am filtering my for in loops, just slightly differently:
        >
        > for (name in obj) {
        > if (!obj.hasOwnProperty(name)) {continue;}
        > ...
        > }
        >
        > I like this because it avoids an extra level of indentation in my code. If I
        > want to add or remove this line it can be done in just a single place
        > instead of at the top and bottom of the loop.

        I do not recommend use of continue. JSLint currently barely tolerates it.




        [Non-text portions of this message have been removed]
      • Douglas Crockford
        ... The purpose of JSLint is not to make you feel good about inadequate coding standards. Since you are refusing to consider my advice to avoid continue, then
        Message 3 of 19 , Nov 17, 2010
        • 0 Attachment
          --- In jslint_com@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
          >
          > In my team code standards, continue and break are only to be used with a label.
          > This is similar to other Best Practice conventions in other languages because
          > it avoids the ambiguity of the continue or break statement.

          The purpose of JSLint is not to make you feel good about inadequate coding standards. Since you are refusing to consider my advice to avoid continue, then I recommend that you turn on the "Tolerate unfiltered for in" option.
        • Rob Richardson
          goto is evil. ... From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf Of Michael Mikowski Sent: Wednesday, November 17, 2010 11:26
          Message 4 of 19 , Nov 17, 2010
          • 0 Attachment
            goto is evil.


            -----Original Message-----
            From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On Behalf Of Michael Mikowski
            Sent: Wednesday, November 17, 2010 11:26 AM
            To: jslint_com@yahoogroups.com
            Subject: Re: [jslint] Re: Filtered for...in

            In my team code standards, continue and break are only to be used with a label.
            This is similar to other Best Practice conventions in other languages because
            it avoids the ambiguity of the continue or break statement. And sometimes, its
            actually quite useful (e.g. break of an outer loop from an inner loop when a
            condition is met).

            Here is a contrived example:

            var
            str_search_model = 'Ford Escort',
            hash_obj_car = {
            escort : { str_model : 'Ford Escort' },
            malibu : { str_model: 'Chevy Malibu'}
            },
            obj_car,
            str_key
            ;

            FIND_CAR:
            for ( str_key in hash_car ){
            if ( ! hash_obj_car.hasOwnProperty(str_name)){ continue FIND_CAR; }
            obj_car = hash_obj_car[str_key];
            if ( obj_car.str_model === str_search_model ){ break FIND_CAR; }
            }

            // and now obj_car is the 'Ford Escort' model, or if not found, undefined






            ________________________________
            From: Douglas Crockford <douglas@...>
            To: jslint_com@yahoogroups.com
            Sent: Wed, November 17, 2010 10:02:35 AM
            Subject: [jslint] Re: Filtered for...in


            --- In jslint_com@yahoogroups.com, Erik Eckhardt <erik@...> wrote:
            >
            > JSLint is complaining that my for...in loop is not filtered. The docs
            > suggest the following format:
            >
            > for (name in obj) {
            > if (obj.hasOwnProperty(name)) {
            > ...
            > }
            > }
            >
            > But I am filtering my for in loops, just slightly differently:
            >
            > for (name in obj) {
            > if (!obj.hasOwnProperty(name)) {continue;}
            > ...
            > }
            >
            > I like this because it avoids an extra level of indentation in my code. If I
            > want to add or remove this line it can be done in just a single place
            > instead of at the top and bottom of the loop.

            I do not recommend use of continue. JSLint currently barely tolerates it.




            [Non-text portions of this message have been removed]
          • Erik Eckhardt
            Could you elaborate on that? I d love to get on the bandwagon but don t know why you would say that. On Wed, Nov 17, 2010 at 10:02 AM, Douglas Crockford ...
            Message 5 of 19 , Nov 17, 2010
            • 0 Attachment
              Could you elaborate on that? I'd love to get on the bandwagon but don't know
              why you would say that.

              On Wed, Nov 17, 2010 at 10:02 AM, Douglas Crockford
              <douglas@...>wrote:

              > I do not recommend use of continue. JSLint currently barely tolerates
              > it.
              >


              [Non-text portions of this message have been removed]
            • Michael Mikowski
              Actually, Douglas, My standards do follow your recommendations about filtering; unfortunately, the example I contrived does not. The intent there was to show
              Message 6 of 19 , Nov 17, 2010
              • 0 Attachment
                Actually, Douglas,

                My standards do follow your recommendations about filtering; unfortunately, the
                example I contrived does not.
                The intent there was to show the use of a label for continue and break. It was
                another poster who wanted to use continue as a filter method.

                Someone else mentioned that "goto is evil". Yes, but the labels are not
                intended for use with goto. They are intended to mark a loop so that if one
                uses continue or break, its obvious what control structure is affected.

                Cheers, Mike




                ________________________________
                From: Douglas Crockford <douglas@...>
                To: jslint_com@yahoogroups.com
                Sent: Wed, November 17, 2010 10:35:50 AM
                Subject: [jslint] Re: Filtered for...in


                --- In jslint_com@yahoogroups.com, Michael Mikowski <z_mikowski@...> wrote:
                >
                > In my team code standards, continue and break are only to be used with a label.
                >
                > This is similar to other Best Practice conventions in other languages because

                > it avoids the ambiguity of the continue or break statement.

                The purpose of JSLint is not to make you feel good about inadequate coding
                standards. Since you are refusing to consider my advice to avoid continue, then
                I recommend that you turn on the "Tolerate unfiltered for in" option.




                [Non-text portions of this message have been removed]
              • Marcel Duran
                Here s an old function from a greasemonkey script I wrote a few years ago that uses label and break instead of a bunch of control variables to properly break
                Message 7 of 19 , Nov 18, 2010
                • 0 Attachment
                  Here's an old function from a greasemonkey script I wrote a few years ago
                  that uses label and break instead of a bunch of control variables to
                  properly break the outer loop when searching for selectors in stylesheets:

                  var changeCSS = function (selector, property, value) {
                  var i, j, lenR, rules, found,
                  doc = document,
                  styleSheets = doc.styleSheets,
                  lenS = styleSheets.length,
                  jsProperty = property.replace(/-([\s\S])/g, function () {
                  return arguments[1].toUpperCase();
                  });

                  // get selector and add/change style
                  css:
                  for (i = 0; i < lenS; i += 1) {
                  rules = styleSheets[i].cssRules;
                  for (j = 0, lenR = rules.length; j < lenR; j += 1) {
                  if (rules[j].selectorText === selector) {
                  found = true;
                  rules[j].style[jsProperty] = value;
                  break css;
                  }
                  }
                  }

                  // add selector when not found
                  if (!found) {
                  styleSheets[i - 1].insertRule(selector + '{' + property + ':' +
                  value + ';}', j - 1);
                  }
                  };

                  And it's JSLint approved.


                  Marcel

                  On Wed, Nov 17, 2010 at 6:35 PM, Michael Mikowski <z_mikowski@...>wrote:

                  >
                  >
                  > Actually, Douglas,
                  >
                  > My standards do follow your recommendations about filtering; unfortunately,
                  > the
                  > example I contrived does not.
                  > The intent there was to show the use of a label for continue and break. It
                  > was
                  > another poster who wanted to use continue as a filter method.
                  >
                  > Someone else mentioned that "goto is evil". Yes, but the labels are not
                  > intended for use with goto. They are intended to mark a loop so that if one
                  >
                  > uses continue or break, its obvious what control structure is affected.
                  >
                  > Cheers, Mike
                  >
                  >
                  > ________________________________
                  > From: Douglas Crockford <douglas@... <douglas%40crockford.com>>
                  > To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
                  > Sent: Wed, November 17, 2010 10:35:50 AM
                  >
                  > Subject: [jslint] Re: Filtered for...in
                  >
                  > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Michael
                  > Mikowski <z_mikowski@...> wrote:
                  > >
                  > > In my team code standards, continue and break are only to be used with a
                  > label.
                  > >
                  > > This is similar to other Best Practice conventions in other languages
                  > because
                  >
                  > > it avoids the ambiguity of the continue or break statement.
                  >
                  > The purpose of JSLint is not to make you feel good about inadequate coding
                  > standards. Since you are refusing to consider my advice to avoid continue,
                  > then
                  > I recommend that you turn on the "Tolerate unfiltered for in" option.
                  >
                  > [Non-text portions of this message have been removed]
                  >
                  >
                  >



                  --
                  Marcel Duran


                  [Non-text portions of this message have been removed]
                • Erik Eckhardt
                  Douglas, The only thing I could find about continue related to jslint was a one-liner: Avoid use of the continue statement. It tends to obscure the control
                  Message 8 of 19 , Nov 18, 2010
                  • 0 Attachment
                    Douglas,

                    The only thing I could find about continue related to jslint was a
                    one-liner:

                    Avoid use of the continue statement. It tends to obscure the control flow of
                    the function.

                    In the case that I described (filtering a for...in loop at the top), I think
                    the continue statement does the opposite: it makes clearer the purpose and
                    control flow of the function. Instead of a person having to scan to the
                    bottom of a potentially lengthy 'if' block to see whether there is an 'else'
                    statement, he can see right away that no other code is executed and why.

                    Since there is no security issue and no clearly objective measure that makes
                    the continue statement always wrong (thus use of the word "tends'), would
                    you consider adding support for detecting the continue statement as a valid
                    filtering of for...in?

                    It isn't anything like, say, leaving semicolons out. Try to minify script
                    that's missing semicolons and you might bash your knuckles.

                    Erik

                    On Wed, Nov 17, 2010 at 10:49 AM, Erik Eckhardt <erik@...> wrote:

                    > Could you elaborate on that? I'd love to get on the bandwagon but don't
                    > know why you would say that.
                    >
                    >
                    > On Wed, Nov 17, 2010 at 10:02 AM, Douglas Crockford <douglas@...
                    > > wrote:
                    >
                    >> I do not recommend use of continue. JSLint currently barely tolerates
                    >> it.
                    >>
                    >
                    >


                    [Non-text portions of this message have been removed]
                  • Cheney, Edward A SSG RES USAR USARC
                    Erik, The problem with the continue statement is that its use obscures logic. It is clear that a loop will break or it is endless. An endless loop is
                    Message 9 of 19 , Nov 18, 2010
                    • 0 Attachment
                      Erik,

                      The problem with the continue statement is that its use obscures logic. It is clear that a loop will break or it is endless. An endless loop is considered a broken program. Since a correct loop will end what is important is if it ends at the defined point of termination or if the loop ends prematurely. The continue statement does nothing to make this more clear and instead confuses the interpretation of potential break points. The break statement, conversely, is absolutely imperative to this clarity. Premature loop termination is absolutely essential to certain operations where the variable representing the looping index is used in closure, because then that variable can be used against the stated loop length to derive conditional conclusions outside of a containing function.

                      In other words the continue statement can always be mitigated through the use of more sturdy logic while its use can confuse other logic that is essential not open to mitigation. Therefore, it is in your best interest to not use the continue statement. Additionally, if you are assigning a variable set in closure representing any of the three object types in a condition containing a continue statement you are likely opening a covert channel in your code, which is a potential security weakness if your code is complex enough to contain multiple points of disparate execution.

                      If you post an example of JavaScript using the continue statement I can show how to mitigate its use.

                      Austin Cheney, CISSP
                      http://prettydiff.com/
                    • Erik Eckhardt
                      Austin, The example was: for (name in obj) { if (!obj.hasOwnProperty(name)) {continue;} ... } In my opinion this is little different than this greatly-upvoted
                      Message 10 of 19 , Nov 18, 2010
                      • 0 Attachment
                        Austin,

                        The example was:

                        for (name in obj) {
                        if (!obj.hasOwnProperty(name)) {continue;}
                        ...
                        }

                        In my opinion this is little different than this greatly-upvoted Stack
                        Overflow answer about multiple return statements in
                        procedures<http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement/36714#36714>.
                        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. Finally there is a
                        38-vote answer about minimizing return statements because some poor bloke
                        could get confused.

                        In theory, there is no difference between theory and practice. In practice,
                        there is often a big difference. Programmers, apparently, in practice prefer
                        being able to do things early when it makes sense. 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.

                        A suggestion to Douglas: could jslint be made to separate the issues of
                        unfiltered for...in and continue? If jslint will be recommending against use
                        of 'continue' I will take it under advisemen. IN the meantime, how about
                        coding to warn about its use, but give me an option to allow it? Don't tell
                        me incorrectly that I didn't filter my for...in loop *when I did*,* *just
                        not the way you *like* it done.

                        I love jslint. It's faster than running my code over and over and tracking
                        down each bug one at a time. It helps me find bugs I didn't even know I had
                        yet (just this week, a misspelled variable was preventing the update of
                        something I thought was updating). I'd pay money for it. I'd consider it a
                        great kindness to allow me my style choice without punishment (either ignore
                        the unfiltered for...in warning or not get them at all, neither of which is
                        good). Whatever the theoretical arguments against 'continue' are, in
                        practice I find it useful and more clear sometimes. Please don't penalize me
                        in jslint for a decision that is purely one of style.

                        Erik

                        On Thu, Nov 18, 2010 at 2:23 PM, Cheney, Edward A SSG RES USAR USARC <
                        austin.cheney@...> wrote:

                        >
                        >
                        > Erik,
                        >
                        > The problem with the continue statement is that its use obscures logic. It
                        > is clear that a loop will break or it is endless. An endless loop is
                        > considered a broken program. Since a correct loop will end what is important
                        > is if it ends at the defined point of termination or if the loop ends
                        > prematurely. The continue statement does nothing to make this more clear and
                        > instead confuses the interpretation of potential break points. The break
                        > statement, conversely, is absolutely imperative to this clarity. Premature
                        > loop termination is absolutely essential to certain operations where the
                        > variable representing the looping index is used in closure, because then
                        > that variable can be used against the stated loop length to derive
                        > conditional conclusions outside of a containing function.
                        >
                        > In other words the continue statement can always be mitigated through the
                        > use of more sturdy logic while its use can confuse other logic that is
                        > essential not open to mitigation. Therefore, it is in your best interest to
                        > not use the continue statement. Additionally, if you are assigning a
                        > variable set in closure representing any of the three object types in a
                        > condition containing a continue statement you are likely opening a covert
                        > channel in your code, which is a potential security weakness if your code is
                        > complex enough to contain multiple points of disparate execution.
                        >
                        > If you post an example of JavaScript using the continue statement I can
                        > show how to mitigate its use.
                        >
                        > Austin Cheney, CISSP
                        > http://prettydiff.com/
                        > __._,
                        >


                        [Non-text portions of this message have been removed]
                      • Carlos Vadillo
                        ... I think you can always write an alternative code that conveys better your intentions: var changeCSS = function (selector, property, value) { var i, rules,
                        Message 11 of 19 , Nov 18, 2010
                        • 0 Attachment
                          --- In jslint_com@yahoogroups.com, Marcel Duran <contact@...> wrote:
                          >
                          > Here's an old function from a greasemonkey script I wrote a few years ago
                          > that uses label and break instead of a bunch of control variables to
                          > properly break the outer loop when searching for selectors in stylesheets:
                          >
                          > var changeCSS = function (selector, property, value) {
                          > var i, j, lenR, rules, found,
                          > doc = document,
                          > styleSheets = doc.styleSheets,
                          > lenS = styleSheets.length,
                          > jsProperty = property.replace(/-([\s\S])/g, function () {
                          > return arguments[1].toUpperCase();
                          > });
                          >
                          > // get selector and add/change style
                          > css:
                          > for (i = 0; i < lenS; i += 1) {
                          > rules = styleSheets[i].cssRules;
                          > for (j = 0, lenR = rules.length; j < lenR; j += 1) {
                          > if (rules[j].selectorText === selector) {
                          > found = true;
                          > rules[j].style[jsProperty] = value;
                          > break css;
                          > }
                          > }
                          > }
                          >
                          > // add selector when not found
                          > if (!found) {
                          > styleSheets[i - 1].insertRule(selector + '{' + property + ':' +
                          > value + ';}', j - 1);
                          > }
                          > };
                          >
                          > And it's JSLint approved.
                          >
                          >
                          > Marcel
                          >
                          > On Wed, Nov 17, 2010 at 6:35 PM, Michael Mikowski <z_mikowski@...>wrote:
                          >
                          > >
                          > >
                          > > Actually, Douglas,
                          > >
                          > > My standards do follow your recommendations about filtering; unfortunately,
                          > > the
                          > > example I contrived does not.
                          > > The intent there was to show the use of a label for continue and break. It
                          > > was
                          > > another poster who wanted to use continue as a filter method.
                          > >
                          > > Someone else mentioned that "goto is evil". Yes, but the labels are not
                          > > intended for use with goto. They are intended to mark a loop so that if one
                          > >
                          > > uses continue or break, its obvious what control structure is affected.
                          > >
                          > > Cheers, Mike
                          > >
                          > >
                          > > ________________________________
                          > > From: Douglas Crockford <douglas@... <douglas%40crockford.com>>
                          > > To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>
                          > > Sent: Wed, November 17, 2010 10:35:50 AM
                          > >
                          > > Subject: [jslint] Re: Filtered for...in
                          > >
                          > > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Michael
                          > > Mikowski <z_mikowski@> wrote:
                          > > >
                          > > > In my team code standards, continue and break are only to be used with a
                          > > label.
                          > > >
                          > > > This is similar to other Best Practice conventions in other languages
                          > > because
                          > >
                          > > > it avoids the ambiguity of the continue or break statement.
                          > >
                          > > The purpose of JSLint is not to make you feel good about inadequate coding
                          > > standards. Since you are refusing to consider my advice to avoid continue,
                          > > then
                          > > I recommend that you turn on the "Tolerate unfiltered for in" option.
                          > >
                          > > [Non-text portions of this message have been removed]
                          > >
                          > >
                          > >
                          >
                          >
                          >
                          > --
                          > Marcel Duran
                          >
                          >
                          > [Non-text portions of this message have been removed]
                          >

                          I think you can always write an alternative code that conveys better your intentions:


                          var changeCSS = function (selector, property, value) {
                          var i,
                          rules,
                          found,
                          doc = document,
                          styleSheets = doc.styleSheets,
                          lenS = styleSheets.length,
                          jsProperty = property.replace(/-([\s\S])/g, function () {
                          return arguments[1].toUpperCase();
                          }),
                          findSelectorInRules = function (rules) {
                          var j,
                          lenR;

                          for (j = 0, lenR = rules.length; j < lenR; j += 1) {
                          if (rules[j].selectorText === selector) {
                          rules[j].style[jsProperty] = value;
                          return true;
                          }
                          }
                          return false;
                          },
                          findSelectorInStyleSheets = function (styleSheets) {
                          var i,
                          rules,
                          lenS = styleSheets.length;

                          for (i = 0; i < lenS; i += 1) {
                          rules = styleSheets[i].cssRules;
                          if (findSelectorInRules(rules)) {
                          return true;
                          }
                          }
                          return false;
                          },
                          insertRuleAtEnd = function (styleSheets) {
                          var lenS = styleSheets.length - 1,
                          lenR = styleSheets[lenS].cssRules.length - 1;

                          styleSheets[lenS].insertRule(selector + '{' + property + ':' + value + ';}', lenR);
                          };

                          // get selector and add/change style
                          if (!findSelectorInStyleSheets(styleSheets)) {
                          insertRuleAtEnd(styleSheets);
                          }
                          };

                          As I understood the code it only has one function, to insert a selector that does not exist. Then the function only have two statements: The first to determine if the selector is present in the styleSheets and the second to insert the selector at the end of the arrays.

                          By breaking your code into nested functions what you gain is a piece of code that can be read by a human: If I cannot find the selector in the current style sheets then I will insert it at the end. How you find the selector is not important at the narrative of the function. Then you go to next level of functions, and have a narrative also: review all the styleSheets and find the selector in their rules. So on and so forth.

                          No need for continue, no need for break, no need for labels and a code that is easy to read
                        • Marcel Duran
                          Hi Carlos, I really like your solution, it s much clearer. As I mentioned this is an old code I wrote a few years ago which uses label/brake, I certainly won t
                          Message 12 of 19 , Nov 18, 2010
                          • 0 Attachment
                            Hi Carlos,

                            I really like your solution, it's much clearer. As I mentioned this is an
                            old code I wrote a few years ago which uses label/brake, I certainly won't
                            wrote the same if I had to. One of the beauties of JavaScript IMO is this
                            always evolving coding style nature when the all the pieces has always been
                            there.

                            Thanks,

                            Marcel

                            On Thu, Nov 18, 2010 at 10:36 PM, Carlos Vadillo
                            <carlos.vadillo@...>wrote:

                            >
                            >
                            >
                            > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>, Marcel
                            > Duran <contact@...> wrote:
                            > >
                            > > Here's an old function from a greasemonkey script I wrote a few years ago
                            > > that uses label and break instead of a bunch of control variables to
                            > > properly break the outer loop when searching for selectors in
                            > stylesheets:
                            > >
                            > > var changeCSS = function (selector, property, value) {
                            > > var i, j, lenR, rules, found,
                            > > doc = document,
                            > > styleSheets = doc.styleSheets,
                            > > lenS = styleSheets.length,
                            > > jsProperty = property.replace(/-([\s\S])/g, function () {
                            > > return arguments[1].toUpperCase();
                            > > });
                            > >
                            > > // get selector and add/change style
                            > > css:
                            > > for (i = 0; i < lenS; i += 1) {
                            > > rules = styleSheets[i].cssRules;
                            > > for (j = 0, lenR = rules.length; j < lenR; j += 1) {
                            > > if (rules[j].selectorText === selector) {
                            > > found = true;
                            > > rules[j].style[jsProperty] = value;
                            > > break css;
                            > > }
                            > > }
                            > > }
                            > >
                            > > // add selector when not found
                            > > if (!found) {
                            > > styleSheets[i - 1].insertRule(selector + '{' + property + ':' +
                            > > value + ';}', j - 1);
                            > > }
                            > > };
                            > >
                            > > And it's JSLint approved.
                            > >
                            > >
                            > > Marcel
                            > >
                            > > On Wed, Nov 17, 2010 at 6:35 PM, Michael Mikowski <z_mikowski@...>wrote:
                            >
                            > >
                            > > >
                            > > >
                            > > > Actually, Douglas,
                            > > >
                            > > > My standards do follow your recommendations about filtering;
                            > unfortunately,
                            > > > the
                            > > > example I contrived does not.
                            > > > The intent there was to show the use of a label for continue and break.
                            > It
                            > > > was
                            > > > another poster who wanted to use continue as a filter method.
                            > > >
                            > > > Someone else mentioned that "goto is evil". Yes, but the labels are not
                            > > > intended for use with goto. They are intended to mark a loop so that if
                            > one
                            > > >
                            > > > uses continue or break, its obvious what control structure is affected.
                            > > >
                            > > > Cheers, Mike
                            > > >
                            > > >
                            > > > ________________________________
                            > > > From: Douglas Crockford <douglas@... <douglas%40crockford.com>>
                            > > > To: jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com><jslint_com%
                            > 40yahoogroups.com>
                            >
                            > > > Sent: Wed, November 17, 2010 10:35:50 AM
                            > > >
                            > > > Subject: [jslint] Re: Filtered for...in
                            > > >
                            > > > --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com><jslint_com%
                            > 40yahoogroups.com>, Michael
                            >
                            > > > Mikowski <z_mikowski@> wrote:
                            > > > >
                            > > > > In my team code standards, continue and break are only to be used
                            > with a
                            > > > label.
                            > > > >
                            > > > > This is similar to other Best Practice conventions in other languages
                            > > > because
                            > > >
                            > > > > it avoids the ambiguity of the continue or break statement.
                            > > >
                            > > > The purpose of JSLint is not to make you feel good about inadequate
                            > coding
                            > > > standards. Since you are refusing to consider my advice to avoid
                            > continue,
                            > > > then
                            > > > I recommend that you turn on the "Tolerate unfiltered for in" option.
                            > > >
                            > > > [Non-text portions of this message have been removed]
                            > > >
                            > > >
                            > > >
                            > >
                            > >
                            > >
                            > > --
                            > > Marcel Duran
                            >
                            > >
                            > >
                            > > [Non-text portions of this message have been removed]
                            > >
                            >
                            > I think you can always write an alternative code that conveys better your
                            > intentions:
                            >
                            >
                            > var changeCSS = function (selector, property, value) {
                            > var i,
                            > rules,
                            > found,
                            > doc = document,
                            > styleSheets = doc.styleSheets,
                            > lenS = styleSheets.length,
                            > jsProperty = property.replace(/-([\s\S])/g, function () {
                            > return arguments[1].toUpperCase();
                            > }),
                            > findSelectorInRules = function (rules) {
                            > var j,
                            > lenR;
                            >
                            >
                            > for (j = 0, lenR = rules.length; j < lenR; j += 1) {
                            > if (rules[j].selectorText === selector) {
                            > rules[j].style[jsProperty] = value;
                            > return true;
                            > }
                            > }
                            > return false;
                            > },
                            > findSelectorInStyleSheets = function (styleSheets) {
                            > var i,
                            > rules,
                            > lenS = styleSheets.length;
                            >
                            >
                            > for (i = 0; i < lenS; i += 1) {
                            > rules = styleSheets[i].cssRules;
                            > if (findSelectorInRules(rules)) {
                            > return true;
                            > }
                            > }
                            > return false;
                            > },
                            > insertRuleAtEnd = function (styleSheets) {
                            > var lenS = styleSheets.length - 1,
                            > lenR = styleSheets[lenS].cssRules.length - 1;
                            >
                            > styleSheets[lenS].insertRule(selector + '{' + property + ':' + value +
                            > ';}', lenR);
                            > };
                            >
                            >
                            > // get selector and add/change style
                            > if (!findSelectorInStyleSheets(styleSheets)) {
                            > insertRuleAtEnd(styleSheets);
                            > }
                            > };
                            >
                            > As I understood the code it only has one function, to insert a selector
                            > that does not exist. Then the function only have two statements: The first
                            > to determine if the selector is present in the styleSheets and the second to
                            > insert the selector at the end of the arrays.
                            >
                            > By breaking your code into nested functions what you gain is a piece of
                            > code that can be read by a human: If I cannot find the selector in the
                            > current style sheets then I will insert it at the end. How you find the
                            > selector is not important at the narrative of the function. Then you go to
                            > next level of functions, and have a narrative also: review all the
                            > styleSheets and find the selector in their rules. So on and so forth.
                            >
                            > No need for continue, no need for break, no need for labels and a code that
                            > is easy to read
                            >
                            >
                            >



                            --
                            Marcel Duran


                            [Non-text portions of this message have been removed]
                          • Cheney, Edward A SSG RES USAR USARC
                            Erik, ... I deleted my Stack Overflow account in late spring. Popularity is not a correlation to accuracy. ... There is nothing wrong with multiple exit
                            Message 13 of 19 , Nov 19, 2010
                            • 0 Attachment
                              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/
                            • Paul
                              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
                              Message 14 of 19 , Nov 19, 2010
                              • 0 Attachment
                                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.


                                --- In jslint_com@yahoogroups.com, "Cheney, Edward A SSG RES USAR USARC" <austin.cheney@...> wrote:
                                >
                                > Erik,
                                >
                                > The problem with the continue statement is that its use obscures logic. It is clear that a loop will break or it is endless. An endless loop is considered a broken program. Since a correct loop will end what is important is if it ends at the defined point of termination or if the loop ends prematurely. The continue statement does nothing to make this more clear and instead confuses the interpretation of potential break points. The break statement, conversely, is absolutely imperative to this clarity. Premature loop termination is absolutely essential to certain operations where the variable representing the looping index is used in closure, because then that variable can be used against the stated loop length to derive conditional conclusions outside of a containing function.
                                >
                                > In other words the continue statement can always be mitigated through the use of more sturdy logic while its use can confuse other logic that is essential not open to mitigation. Therefore, it is in your best interest to not use the continue statement. Additionally, if you are assigning a variable set in closure representing any of the three object types in a condition containing a continue statement you are likely opening a covert channel in your code, which is a potential security weakness if your code is complex enough to contain multiple points of disparate execution.
                                >
                                > If you post an example of JavaScript using the continue statement I can show how to mitigate its use.
                                >
                                > Austin Cheney, CISSP
                                > http://prettydiff.com/
                                >
                              • 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 15 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 16 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 17 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 18 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.