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

Re: [jslint] Re: minor rule relaxation request

Expand Messages
  • 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 1 of 6 , Mar 6 10:47 AM
    • 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 2 of 6 , Mar 6 10:59 AM
      • 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 3 of 6 , Mar 6 11:09 AM
        • 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 4 of 6 , Mar 7 6:43 AM
          • 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.