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

Re: minor rule relaxation request

Expand Messages
  • Douglas Crockford
    ... My advice is that you get used to it. For the cost of two characters, your code will be less error prone. That is a really good tradeoff.
    Message 1 of 6 , Mar 6, 2009
    • 0 Attachment
      --- In jslint_com@yahoogroups.com, "zoney70" <zoney70@...> wrote:
      >
      > I find the requirement for using braces excessively anal in such if
      > compounds as:
      > if (/*expression*/) {/*single statement*/} else {/*single
      > statement*/}

      My advice is that you get used to it. For the cost of two characters, your code will be less error prone. That is a really good tradeoff.
    • Michael Lorton
      True that! Most C-like languages allow the brace-less consequent, but it s evil! Evil, I say! Seriously, it s difficult to read and error-prone. M.
      Message 2 of 6 , Mar 6, 2009
      • 0 Attachment
        True that! Most C-like languages allow the brace-less consequent, but it's evil! Evil, I say!

        Seriously, it's difficult to read and error-prone.

        M.




        ________________________________
        From: Douglas Crockford <douglas@...>
        To: jslint_com@yahoogroups.com
        Sent: Friday, March 6, 2009 10:44:37 AM
        Subject: [jslint] Re: minor rule relaxation request

        --- In jslint_com@yahoogroups.com, "zoney70" <zoney70@...> wrote:
        >
        > I find the requirement for using braces excessively anal in such if
        > compounds as:
        > if (/*expression*/) {/*single statement*/} else {/*single
        > statement*/}

        My advice is that you get used to it. For the cost of two characters, your code will be less error prone. That is a really good tradeoff.



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

        Yahoo! Groups Links



        [Non-text portions of this message have been removed]
      • James Clark
        ... Another option is to just add the feature to your own copy of fulljslint.js. I did this for just this scenario. Add a braces option, then add a boolean
        Message 3 of 6 , Mar 6, 2009
        • 0 Attachment
          > --- In jslint_com@yahoogroups.com <mailto:jslint_com%40yahoogroups.com>,
          > "zoney70" <zoney70@...> wrote:
          > >
          > > I find the requirement for using braces excessively anal in such if
          > > compounds as:
          > > if (/*expression*/) {/*single statement*/} else {/*single
          > > statement*/}
          >

          Douglas Crockford wrote:
          > My advice is that you get used to it. For the cost of two characters,
          > your code will be less error prone. That is a really good tradeoff.

          Another option is to just add the feature to your own copy of
          fulljslint.js. I did this for just this scenario. Add a 'braces'
          option, then add a boolean argument to the 'block' function. Then in
          each place where block() is called, I passed either true or
          !option.braces, depending on whether the braces are truly mandatory
          (function, try/catch/finally) or not (all others).

          -jamie
        • zoney70
          ... it s evil! Evil, I say! ... it s evil! Evil, I say! ... Seriously, having lived on the planet for seven decades and programmed for nearly five of them, I
          Message 4 of 6 , Mar 6, 2009
          • 0 Attachment
            --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
            >
            > True that! Most C-like languages allow the brace-less consequent, but
            it's evil! Evil, I say!
            >
            > Seriously, it's difficult to read and error-prone.
            >
            > M.

            --- In jslint_com@yahoogroups.com, Michael Lorton <mlorton@...> wrote:
            >
            > True that! Most C-like languages allow the brace-less consequent, but
            it's evil! Evil, I say!
            >
            > Seriously, it's difficult to read and error-prone.
            >
            > M.
            >

            Seriously, having lived on the planet for seven decades and programmed
            for nearly five of them, I have yet to find this usage in my own code
            either "error-prone" or "difficult to read" (actually the opposite). I
            consider it merely unwieldy notational nonsense that adds no utility.

            It is true that a careless incompetent can destroy any program by
            inserting statements willy-nilly, but who would let a careless
            incompetent anywhere near well-designed code?

            What I can't understand is options to allow eval (truly evil), and
            sloppy line breaks yet insist on those unnecessary braces! This smells
            to me more like a desire to make implementation of jslint easy than any
            particular zeal for my welfare. But, I have observed that phenomenon
            for decades.
          • Douglas Crockford
            ... The eval exclusion was for the benefit of JSONT and json2. They represent uses of eval that are beneficial. I have no excuse for the line breaking option.
            Message 5 of 6 , Mar 7, 2009
            • 0 Attachment
              --- In jslint_com@yahoogroups.com, "zoney70" <zoney70@...> wrote:
              > What I can't understand is options to allow eval (truly evil), and
              > sloppy line breaks yet insist on those unnecessary braces! This smells
              > to me more like a desire to make implementation of jslint easy than any
              > particular zeal for my welfare. But, I have observed that phenomenon
              > for decades.

              The eval exclusion was for the benefit of JSONT and json2. They represent uses of eval that are beneficial.

              I have no excuse for the line breaking option. Who would cry if I removed it?
            Your message has been successfully submitted and would be delivered to recipients shortly.