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

Re: continue

Expand Messages
  • 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 1 of 28 , Jun 20 5:11 AM
    • 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 2 of 28 , Jun 20 6:06 AM
      • 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 3 of 28 , Jun 20 7:51 AM
        • 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 4 of 28 , Jun 20 8:24 AM
          • 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 5 of 28 , Jun 20 8:56 AM
            • 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 6 of 28 , Jun 20 12:44 PM
              • 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 7 of 28 , Jun 20 12:58 PM
                • 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 8 of 28 , Jun 20 1:47 PM
                  • 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 9 of 28 , Jun 20 2:38 PM
                    • 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 10 of 28 , Jun 20 3:02 PM
                      • 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 11 of 28 , Jun 20 6:06 PM
                        • 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 12 of 28 , Jun 20 7:03 PM
                          • 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.