Javascript parser

[Jeff Robichaud]

Hi, I would like to know if there exists a tool that one can use to test
some javascript code before actually running it ? Something that would check
the syntax at least ? I found that most mistakes that I make when coding in
javascript are syntax-related.

Here's a typical scenario: I use a function like getElementByID. Notice the
big D...In Internet Explorer I get the classic "object doesn't support this
property or method" message, line X, char X that are of no use because they
point somewhere I can't relate. Such an error could have been easily spotted
with a parser or compiler.

 

[bumbleguppy]

Download firefox.

http://getfirefox.com

In the menu when viewing your html page, go to Tools/Javascript
Console.

If you can't download firefox, try this:


window.onerror=errHandler;
var msgArray = new Array(),urlArray = new Array(),lnoArray = new
Array();

//paramenters of error functions(determined by default, not my
idea...):
//error message, url where error occurred and line number

function errHandler(msg, url, lno) {
msgArray[msgArray.length] = msg;
urlArray[urlArray.length] = url;
lnoArray[lnoArray.length] = lno;
return true;
}

function displayErrors(){
var s='Javascript Error Report\n\n\n';
if(msgArray.length){
for(var i=0;i<msgArray.length;i++){
s+='line '+lnoArray+':\n'+msgArray+'\n\n';
}
alert(s);
}
}

then just call 'displayErrors()' where you want to see the report. The
"return true" in the error handler will keep Internet Exporer from
generating those annoying alert boxes (and if you have the C++ debugger
installed, the debugger won't load either).

 

[Ivo]

Hi, I would like to know if there exists a tool that one can use to test
some javascript code before actually running it ? Something that would check
the syntax at least ?

http://www.crockford.com/javascript/jslint.html

hth

 

[Jeff Robichaud]

Firefox javascript console: that will do the trick I think.
jslint: not bad but still incomplete: it won't catch errors related to
methods that are misspelled.

Thank you guys!

 

[Ivo]

"Jeff Robichaud" wrote

Firefox javascript console: that will do the trick I think.
jslint: not bad but still incomplete: it won't catch errors related to
methods that are misspelled.

Of course not, that would be very bad! How can jslint possibly know you have
not written your own getElementByID with capital D? A word is only
misspelled in the eye of the beholder. Expecting these things is not
understanding the underlying mechanism. Really, jslint is much more
informative than any browser js console if you know how to read its reports.
Calling it "not bad" is an insult, not only to its creator, but to the
undoubtedly hundreds of us that use it every day, and admire it for its
accuracy, speed, and usefullness. I encourage you to have another look at
it, and keep trying a bit longer before jumping to conclusions.

 

[Michael Winter]

Jeff Robichaud wrote:

[snip]

Here's a typical scenario: I use a function like getElementByID.

The getElementById method, as with any host object or property, has
nothing to do with the language itself. It's not a syntax error, just
a typo. Expecting a lint tool to correct errors like that is unrealistic.

[snip]

Mike

 

[Douglas Crockford]

Here's a typical scenario: I use a function like getElementByID.

The getElementById method, as with any host object or property, has
nothing to do with the language itself. It's not a syntax error, just a
typo. Expecting a lint tool to correct errors like that is unrealistic.

Suppose that JSLINT's report contained a list of all of the member names
that it sees. It might be easier to spot a misspelled name in that list
than in the source. What do you think?

http://www.crockford.com/javascript/lint.html

 

[Michael Winter]

Douglas Crockford wrote:

[snip]

Suppose that JSLINT's report contained a list of all of the member names
that it sees. It might be easier to spot a misspelled name in that list
than in the source. What do you think?

A rhetorical question I think, but yes, it might. [Just thinking aloud
now, and briefly - time for sleep. I'm sure you've thought of what I'm
about to write.]

Assuming a sorted list and mistakes in the middle, or at the end, of
member names, this would place duplicates side-by-side for one-off
errors. If it was simple to match nearly-identical strings, that
condition could be flagged as a warning. It could be implemented for
strings that only differ by case.

It wouldn't help if all occurrences (including single uses) were
erroneous. Its utility might also be reduced in OO-heavy code which
would produce a very long list.

Of course, one could just try typing a little more carefully.

Mike

 

[Randy Webb]

Douglas Crockford wrote:

[snip]

Suppose that JSLINT's report contained a list of all of the member
names that it sees. It might be easier to spot a misspelled name in
that list than in the source. What do you think?

A rhetorical question I think, but yes, it might. [Just thinking aloud
now, and briefly - time for sleep. I'm sure you've thought of what I'm
about to write.]

Assuming a sorted list and mistakes in the middle, or at the end, of
member names, this would place duplicates side-by-side for one-off
errors. If it was simple to match nearly-identical strings, that
condition could be flagged as a warning. It could be implemented for
strings that only differ by case.

It wouldn't help if all occurrences (including single uses) were
erroneous. Its utility might also be reduced in OO-heavy code which
would produce a very long list.

Of course, one could just try typing a little more carefully.

What if it only gave you a list of unknown variable/member names? That
might, or might not, make things easier to notice. If it disregarded
getElementById but showed you getELementById, then you would know to
look for it.

 

[Douglas Crockford]

Suppose that JSLINT's report contained a list of all of the member

names that it sees. It might be easier to spot a misspelled name in
that list than in the source. What do you think?

A rhetorical question I think, but yes, it might. [Just thinking aloud
now, and briefly - time for sleep. I'm sure you've thought of what I'm
about to write.]

Assuming a sorted list and mistakes in the middle, or at the end, of
member names, this would place duplicates side-by-side for one-off
errors. If it was simple to match nearly-identical strings, that
condition could be flagged as a warning. It could be implemented for
strings that only differ by case.

It wouldn't help if all occurrences (including single uses) were
erroneous. Its utility might also be reduced in OO-heavy code which
would produce a very long list.

Of course, one could just try typing a little more carefully.

What if it only gave you a list of unknown variable/member names? That
might, or might not, make things easier to notice. If it disregarded
getElementById but showed you getELementById, then you would know to
look for it.

What is known or unknown can vary from platform to platform. I could
allow specification of known members with a /*members */ comment,
similar to the /*global */ comment.

http://www.crockford.com/javascript/lint.html

 

[Ivo]

getELementById

Ah, now there 's a nasty one! But serious, a lint program should not care
about wrong and right. It may produce all sorts of lists, and this sounds
like a *very* useful one, not only for finding typo's, but to classify the
items is and must remain up to the user I think. The code on your site is
Tamil to me, because it unlike the majority it concerns itself with what
works and not with what doesn't. Javascript is so flexible, I can program my
own getELementById method, so I expect jslint to allow it too.

 

[Dr John Stockton]

JRS: In article <[email protected]
m>, dated Fri, 4 Mar 2005 14:47:09, seen in

Suppose that JSLINT's report contained a list of all of the member names
that it sees. It might be easier to spot a misspelled name in that list
than in the source. What do you think?

Agreed.


Errors in case are evidently fairly common and hard to spot, as we see
in this group. For example, onKeypress is a perfectly legitimate name;
nevertheless, it is probably a typo, and otherwise almost certainly
injudicious.


The number of names already known to the system is finite, though large;
but a list covering well over 99% of instances-of-use would not be very
long, and could probably be made by RegExp processing of existing
javascript documentation, sorting, de-duplicating, and hand-polishing.
The following line looks semi-promising as a start, mtr being MiniTrue
and DEDUPE being mine :-

mtr -o^ -x+ d:\jscrrefs\jsref\jsr13\*.htm ".*<code>(\w*)</code>.*" =
\1\r | sort | DEDUPE > file.txt

Or there might be a way of getting the list from a browser, or from
browser source code.

It could, IMHO, be useful to report as permissible but suspect any
instances of names that matched a well-known name case-independently but
differed in case.


It would also be useful to report instances of member names that were
duplicated but with case-differences, with a user-selectable parameter
for length (pragmatically, a page may well contain a J loop in one
routine and a j loop in another; but having a name Dustbin and another
DustBin should be viewed with suspicion [ either both should be
identical, or, for easier reading, one might become Dustpan ] ).


Perhaps the best would be to list all distinct names, sorted independent
of case, and annotated symbolically; a user could then process the list
either by eye or by code. Maybe in Column 1 a # for any name that
matches anything but only when case is ignored, else space; in Column 3
a % for a match with a "predefined" name; ...; in Column 2N+1 put the
name itself. Perhaps a column of frequency-count:

# % 2 gettimeout
# 15 getToadStool
# 1 getToadstool
1 getTodeStool

and it is also clear which are probably wrong.

H'mmm - and any name that is not "predefined" and is used only once is
also, IMHO, worth considering, though possibly legitimate especially in
a page with "working but incomplete" status.


IIRC, running jslint kills MSIE4; I consider that a superfluous effect,
perhaps removable by feature detection and/or substitution.

 

[Randy Webb]

Ah, now there 's a nasty one! But serious, a lint program should not care
about wrong and right.

The idea, mine anywany, wasn't one of "this is wrong" but of "this isn't
a known item to me" but as Doublas pointed out that list of known and
unknown can, and is, different across platforms.

Javascript is so flexible, I can program my own getELementById method,
so I expect jslint to allow it too.

And it should. But seeing getELementById in a list of "unknowns" would
key a beginner, and even non-beginners, that it might be a typo.

 

[Csaba2000]

JRS: In article <[email protected]
m>, dated Fri, 4 Mar 2005 14:47:09, seen in

The number of names already known to the system is finite, though large;
but a list covering well over 99% of instances-of-use would not be very
long, and could probably be made by RegExp processing of existing
javascript documentation, sorting, de-duplicating, and hand-polishing.
The following line looks semi-promising as a start, mtr being MiniTrue
and DEDUPE being mine :-

mtr -o^ -x+ d:\jscrrefs\jsref\jsr13\*.htm ".*<code>(\w*)</code>.*" =
\1\r | sort | DEDUPE > file.txt

Or there might be a way of getting the list from a browser, or from
browser source code.

Dr. Stockton's post makes some excellent points, which I'd like to echo.
Probably, the number of "reserved words" across all platforms is no
more than several hundred, say 1000. This is not so very large and
I would think that in the majority of cases, being off in case (or being
one letter too many or too few) might be due cause for noting.
Possibly a: similar to getElementById
type of comment or color indicator (which just possibly, maybe,
might be suppressable on a word by word basis).

Checking for case difference is easy. Testing for one offness is
not so trivial. If I were going to do this, I'd have a dictionary
of lowercase keywords (values (possibly arrays) are the the
actual keywords). When you want to check a user's
supplied entry, lowercase it and check it against the dictionary.
Now you could try all the different combinations of removing
exactly one letter from the user supplied entry to tell whether
the user supplied entry is one letter too big.

To check for the user entry being one letter too small, I
would do this same trick only using the original keywords.
In other words, for getElementById have dictionary
entries for:
getelementbyid, etelementbyid, gtelementbyid, geelementbyid,
getlementbyid, geteementbyid, ...

I figure your dictionary wouldn't have more than about 10000
entries.

Csaba Gabor from Vienna

 

[Douglas Crockford]

Suppose that JSLINT's report contained a list of all of the member names

Dr. Stockton's post makes some excellent points, which I'd like to echo.
Probably, the number of "reserved words" across all platforms is no
more than several hundred, say 1000. This is not so very large and
I would think that in the majority of cases, being off in case (or being
one letter too many or too few) might be due cause for noting.
Possibly a: similar to getElementById
type of comment or color indicator (which just possibly, maybe,
might be suppressable on a word by word basis).

Checking for case difference is easy. Testing for one offness is
not so trivial. If I were going to do this, I'd have a dictionary
of lowercase keywords (values (possibly arrays) are the the
actual keywords). When you want to check a user's
supplied entry, lowercase it and check it against the dictionary.
Now you could try all the different combinations of removing
exactly one letter from the user supplied entry to tell whether
the user supplied entry is one letter too big.

To check for the user entry being one letter too small, I
would do this same trick only using the original keywords.
In other words, for getElementById have dictionary
entries for:
getelementbyid, etelementbyid, gtelementbyid, geelementbyid,
getlementbyid, geteementbyid, ...

I figure your dictionary wouldn't have more than about 10000
entries.

10000 might be a bit of a download. JSLINT now lists all member names.
Please try it. Let me know if it is useful, or if more is required.

http://www.crockford.com/javascript/jslint.html

 

[Csaba2000]

10000 might be a bit of a download. JSLINT now lists all member names.
Please try it. Let me know if it is useful, or if more is required.

http://www.crockford.com/javascript/jslint.html

Despite my post length, I'm actually not very opinionated on the matter.
But I did go check it out, and it failed on this small piece of web page:

<html><body onLoad="tryit()" id=myBody>
<script type='text/javascript'>
// just say no to long function names
// elem = document.getElementById; // didn't work on Firefox
var elem = function (myId) {return document.getElementById(myId);}
function tryit() {alert (elem('myBody').id);}
</script></body></html>

It didn't like that there was no semicolon after the function
(on the var elem line). I put the ';' in and then it passed, but
I thought in case you hadn't run across this type of construct,
you might want to know.

Also, perhaps I don't get something. When I changed capitalization
on .getElementById, then Members listed the new capitalization
but I thought it would be in red or something to alert me to a
capitalization discrepency. Did I miss something?

Regards,
Csaba

 

[Michael Winter]

Csaba2000 wrote:

[snip]

It didn't like that there was no semicolon after the function (on
the var elem line). I put the ';' in and then it passed, but I
thought in case you hadn't run across this type of construct, you
might want to know.

JSLint is correct. You would expect a semicolon after

var num = 6

A function expression is just like any other expression in this regard.

Notice that a function expression is completely different from a
function declaration. This:

function myFunction() {
/* ... */
} /* <-- No semicolon */

is proper. This:

var myFunction = function() {
/* ... */
} /* <-- No semicolon */

isn't.

When I changed capitalization on .getElementById, then Members
listed the new capitalization but I thought it would be in red or
something to alert me to a capitalization discrepency. Did I miss
something?

The change was to list all members encountered in code and the number
of times each individual member was found. The idea is that if you use
a member a couple of times, but type it incorrectly, you'll see more
than one listing.

As Douglas pointed out, what counts as "standard" method names will
vary from platform-to-platform, so it isn't really feasible to
generate a list. A programmer is free to create any properties
desired, with any form of capitialisation. There is nothing (other
than common sense ) stopping someone creating a GetElementByID
method on the document object, so how could a simple automated tool
assert that this is incorrect?

Mike

 

[Ira Baxter]

Hi, I would like to know if there exists a tool that one can use to test
some javascript code before actually running it ? Something that would check
the syntax at least ? I found that most mistakes that I make when coding in
javascript are syntax-related.

See our JavaScript formatter. It parses and reformats, too.

http://www.semanticdesigns.com/Products/LanguageTools/ECMAScriptTools.html