Array constructor or literal

Stevo wrote:

necessary to make it happy.

As I recall from my C days, lint was more like a pre-compiler that would
tell you what real errors/warnings you have in your code, rather than
how it's not suiting one person's style choices. It was used because it
was quicker than running the full compiler.

I fear you misremember. The original lint warned about constructs that
were mostly silently accepted by the extant C compilers. Many of these
were style issues, such as case-fallthrough.

Descendants of that lint, such as Splint, are even more divorced from
particular C compilers. They're often C implementations in their own
right; they just don't produce a translation. Instead they do things
like static data-flow analysis to look for potential use of
uninitialized data, orphaned allocated memory, and possibly-unsafe use
of standard library functions.

Peter van der Linden has a useful discussion of the history and
purpose of lint in his _Expert C Programming: Deep C Secrets_.

So jslint is pretty squarely in the lint fold. The question is really
its author's choices as to what constitutes a "dangerous" or
"undesirable" construction. On this there will of course be
disagreement; but then there is much disagreement over the choices
made by the developers of various lints over the years (and similarly
for compiler warnings).

Since lints traditionally err on the side of false positives, though,
it's my opinion that a good lint is a highly configurable lint. It
should allow specific warnings, and classes of warnings, to be turned
off globally; and it should support source-code annotation to suppress
particular warnings for particular segments of code. (The better
lints, like Splint, also offer a variety of annotations to give the
engine more information about the code.)

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

On Jun 12, 2:09 pm, VK <schools_r... (AT) yahoo (DOT) com> wrote:

On Jun 12, 7:35 pm, Stevo <n... (AT) mail (DOT) invalid> wrote:

I think it's wrong for it to be called jslint when really it should be
called jscrockford.

I'd like to see JSLint with more options to not warn for some of the
things that people find annoying, it could be even more useful for
maintaining consistent team code standards, conventions, and
formatting (not just the author's coding standards). It would also be
useful as an Eclipse plugin.

[snip]

Concerning the OP's question:
there is not a damn difference between Array and [] - they are equal.
One plus of Array is that it allows to set the initial size of the
array without members' initialization:
var a = new Array(1000);
it may be useful if one needs to take extra steps on array elements
above or below the initial size.

There is a possibility that that aspect could be used to improve
efficiency.

If the array's length starts at 0, and items are added continually, as
in a loop, and the final desired length of the Array could be
determined, it might be more efficient to start with an initial load
size, greater than the estimated expected size, then trim the array.
This would mean that step 10 of Array's [[Put]] could be avoided.

9. If ToUint32(P) is less than the value of the length property of A,
then return.
10. Change (or set) the value of the length property of A to
ToUint32(P)+ 1.

^^^ Array [[Put]] - step 10. could be skipped.

It's also perfectly valid to omit the - new keyword.

var e = Error(),
a = Array(200);

Yet JSLint complains.

It would be useful to have configuration for that feature. So that
including a new keyword unnecessarily could be a warning, or vice
versa, or could be optional. I always omit new for Error, and I've
seen Lasse doing this in posts, too.

Of course, it's also valid to use:-

var a = [];
a.length = 200;

Also warnings for throwing primitives, like seen in some pop
libraries:

throw "type property can't be changed";

I would like to have a warning for this. Some browsers provide stack
information for thrown objects. These browsers don't provide a stack
trace if a primitive is thrown.

Garrett

On Jun 13, 12:08*am, Douglas Crockford <nos... (AT) sbcglobal (DOT) net> wrote:

* * *[] and new Array() do the same thing.

And it's a very bad one, indeed : var empty = [];
that can turn even worse : empty.push(empty);
Have to have somebody take a look at it *asap*, jejeje.

--Jorge.

Jorge wrote:

On Jun 13, 12:08 am, Douglas Crockford <nos... (AT) sbcglobal (DOT) net> wrote:
[] and new Array() do the same thing.

And it's a very bad one, indeed : var empty = [];
that can turn even worse : empty.push(empty);
Have to have somebody take a look at it *asap*, jejeje.

There is no semantical difference between

var empty = [];
empty.push(empty);

and

var empty = new Array();
empty.push(empty);

and

var empty = Array();
empty.push(empty);

What exactly are you getting at?


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

Stevo <no (AT) mail (DOT) invalid> wrote:

Duncan Booth wrote:
Dan Rumney <danrumney (AT) warpmail (DOT) net> wrote:

I've no problem against JSLint choosing a specific convention and
applying it. I'm just wondering if there is anything *beyond*
convention to speak in favour of literal over constructor notation.

I do have issues with some of the other warnings generated by jslint
which is why I produced a modified version that lets you ignore
particular error messages if you don't like them.

I think it's wrong for it to be called jslint when really it should be
called jscrockford. It's something that he wrote that highlights
anything that doesn't meet his particular coding standards. They're
not rules, just preferred styles. Not that I'm saying there's anything
wrong with the things it complains about, but they're certainly not
all errors. I tried it once and didn't want to change my code in the
way necessary to make it happy.

As I recall from my C days, lint was more like a pre-compiler that
would tell you what real errors/warnings you have in your code, rather
than how it's not suiting one person's style choices. It was used
because it was quicker than running the full compiler.

Right. I'm not worried what he calls it, but lint for C warns you about

just about every possible thing anyone could object to and you then
configure it to only report about the things you don't like. That's what I
felt jslint should do. What I came up with is still Crockford's program: I
didn't change any of the real guts of his code, all I did was make it
configurable and easier to run from the command line and in that way
somewhat closer to the original lint concept.

Actually the real driver for me to use jslint was that missing out
'optional' semicolons confuses some javascript compression programs so I
wanted to make sure I had all the optional semicolons in the code. Most of
the other warnings I can take or leave, but it did find a few errors such
as variables that were accidentally global because of a missing 'var'.