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

Re: [jslint] Re: minor rule relaxation request

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