This also seems to tie in with the notion that `new` is dangerous. A
little while ago, I actually did forget the `new` on a constructor. It
took me about a minute flat to track the error down. Yeah, a hole in
the array will probably break your code, but that's what you want it
to do.

How silently will it break your code? For the `new` operator, I don't
think it's silent at all. It won't take more than a couple lines or
calls before something throws, because the global object is *not* your
object. A hole in the array: I have no idea, because I've never even
seen it myself. I've never tracked an error down that lead me to a
hole in an array literal. All of these linter things are just made-up
problems based on syntactic obscurities and eccentricities. If they
occurred in reality, they're actually probably more noticeable than
they seem on paper.

On Feb 24, 11:36 am, Dean Landolt <[email protected]> wrote:
> On Thu, Feb 23, 2012 at 4:16 PM, Thom Blake <[email protected]> wrote:
>
> > On Feb 23, 3:57 pm, Dean Landolt <[email protected]> wrote:
> > > > Besides, emacs would kindly have underlined that bit in red for me.
> > > > (and turned yellow any globals)
>
> > > That's called a "linter" ;)
>
> > Funny, I would have just called it a properly-functioning code
> > editor.  Besides, the first one is a syntax error - aren't linters for
> > catching things less obvious than syntax errors?
>
> Linting tools are for static analysis -- static meaning it can be applied
> at design time (e.g. in your editor), not runtime. Yes, the vm will catch
> syntax errors at runtime but what's the point of delaying the inevitable if
> you're already parsing the AST to lint.
>
> But just so you know this isn't a syntax error. It's a perfectly legal
> array hole, and could introduce all kinds of insidious, nearly invisible
> bugs -- a treasure trove of jswtf. And I bet that for an array with a
> number of items these kind of holes wouldn't be nearly as visible as you
> imply. Amusingly one of the main arguments *for* comma-first is that it's
> much harder to see things on the end of a line than the beginning. But this
> is all subjective, and it's not worth fighting over. But it's important to
> note that this array hole issue *is* a problem comma-first is subject to
> that comma-last isn't.
>
> But I'm not trying to get into a style guide pissing match -- I was just
> trying to point out another subtle advantage of linters, especially if you
> practice comma-first.
>
> (FWIW I haven't bothered to configure my editor to lint for me -- I should
> probably do that :)
>
> > I'm terribly confused when people say they let stuff like that into
> > production - "What, you weren't notified of the error as soon as you
> > typed it?"
>
> Yeah, you're probably right. I don't typically use a linter but when I use
> an editor that has this built in I do find it helpful. I've just been too
> lazy to bother configuring my typical editor (Sublime Text 2) w/ this
> functionality.
>
>
>
>
>
>
>
>
>
> > --
> > Job Board:http://jobs.nodejs.org/
> > Posting guidelines:
> >https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en?hl=en

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to