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

Re: [jslint] for comma

Expand Messages
  • Satyam
    The *l* variable is so clearly an intrinsic part of the loop that it doesn t seem to make sense to initialize it elsewhere. If anywhere, it would have to be
    Message 1 of 33 , Jul 18, 2011
      The *l* variable is so clearly an intrinsic part of the loop that it
      doesn't seem to make sense to initialize it elsewhere. If anywhere, it
      would have to be right before the for, to signal its close relation to
      the loop, but then, why not within and make it clearer still? I
      wouldn't like the maintainer of such code to have to look far away to
      figure out what the*l *might contain so the best is the closest and
      there is no closer than within.

      A single comma in the first slot of the for is the only one I would care
      to allow. I would not allow any on the third slot.

      Satyam

      El 16/07/2011 0:40, Emmett Pickerel escribió:
      >
      > My for loops are fairly consistently of this form:
      >
      > for (i=0, l=arr.length; i<l; i = i + 1)
      >
      > What are the caveats of using the comma in this particular case, where
      > it's really being used as a separator?
      >
      > I certainly can't see a case where I'd want to use more than a single
      > comma, or set another property than the loop length. I'd argue it
      > should only be allowed if the value of the second variable is used in
      > the test.
      >
      > ----
      >
      > From: Douglas Crockford <douglas@...
      > <mailto:douglas%40crockford.com>>
      > To: jslint_com@yahoogroups.com <mailto:jslint_com%40yahoogroups.com>
      > Sent: Friday, 15 July 2011, 15:04
      > Subject: Re: [jslint] for comma
      >
      > > --- In jslint_com@yahoogroups.com
      > <mailto:jslint_com%40yahoogroups.com>, Erik Eckhardt <erik@...> wrote:
      > > > > Is anyone still using comma expressions in the control part of for
      > > > statements? I think this is a bad practice, but JSLint currently
      > tolerates
      > > > it.
      >
      > > > Would you be willing to explain (or point us to something
      > explaining) the
      > > > pitfalls of this practice?
      >
      > > There are two. First, the confusion between with comma operator and
      > the comma separator. Having both in the language tends to mask syntax
      > errors. Currently, JSLint tolerates the comma operator only in for
      > statements.
      >
      > > Second, for statements are intended to provide convenience in
      > declaring, testing, and incrementing the induction variable. The comma
      > introduces confusion here as well, over what matter belongs in the
      > body and what matter belongs in the induction specification. Taken to
      > the extreme, you see loops with no bodies at all.
      >
      >
      > ------------------------------------------------------------------------
      >
      > No virus found in this message.
      > Checked by AVG - www.avg.com <http://www.avg.com>
      > Version: 10.0.1390 / Virus Database: 1516/3772 - Release Date: 07/18/11
      >


      [Non-text portions of this message have been removed]
    • Douglas Crockford
      ... So how do you design a programming style? What justification is there for preferring one feature over another? One school says that Just Cuz is an
      Message 33 of 33 , Jul 21, 2011
        > > Can you come up with an example where
        > > their use makes code clearer?
        >
        > Why is that "the real question"?
        >
        > Computer languages are tools. The tools are flexible and varied.
        > Absent a very clear harm, we should not remove flexibility.

        So how do you design a programming style? What justification is there for preferring one feature over another? One school says that "Just Cuz" is an adequate criteria. It just comes down to personal taste. And even though we know it isn't true, we are all free to believe that one person's taste is as good as anyone else's.

        My approach is different. I am trying to have mechanical identification of defects. There are some situations that are difficult to distinguish mechanically, so I now consider all of those cases problematic, even when they are not obviously wrong.

        I believe strongly in subsetting, and my design of subsets factors in things like mechanical identification.

        There are certainly tradeoffs here. I am rejecting some features. But I think this is a minimal cost because those features are not essential. We can still write very good programs without them. The benefit is that we can mechanically detect more defects. An unexpected but significant benefit is that the subset is itself a better language than the whole language, and the programs written in that subset tend to communicate better to other humans.
      Your message has been successfully submitted and would be delivered to recipients shortly.