I am wondering, why does code like this do not issue a warning with jsLint or jsHint
var obj={};
obj.missingFunction();
I understand that it may assume that the function will be eventually defined. But it complains for so many other things, that i thought it would be natural.
I am doing some heavy refactoring, and moving functions out of the global scope to some properties of objects, and it would be great if there was a way to detect errors early in this case
Thanks to the feedback from elclanrs, i have now installed WebStorm IDE and it does the job perfectly, which is fine for me
Related
I know that I can type into Chrome or FF the following command:
Object.keys(window);
but this displays DHTMLX stuff and also function names in which I'm not interested in. And it doesn't display variables in functions that have not been executed yet. We have more than 20,000 lines of JavaScript codebase, so I would prefer static code analyis. I found JavsScript Lint. It is a great tool but I don't know how to use it for displaying global vars.
So I'm searching for memory leaks, forgotten var keywords, and so on...
To do [only] what you're asking, I think you're looking for this:
for each (obj in window) {
if (window.hasOwnProperty(obj)) {
console.log(obj);
}
}
I haven't linted that code, which is unlike me, but you get the idea. Try setting something first (var spam = "spam";) and you'll see it reported on your console, and not the cruft you asked about avoiding.
That said, JLRishe is right; JSLint executes JavaScript in your browser without "phoning home", so feel free to run it. There are also many offline tools for JSLinting your code. I use a plugin for Sublime Text, for instance.
If you'd like some simplest-case html/JavaScript code to "wrap" JSLint, I've got an example here. Just download the latest jslint.js file from Crockford's repository into the same directory, and poof, you're linting with a local copy of JSLint.js. Edit: Added code in a new answer here.
Though understand that you're linting locally with that wrapper or when you visit JSLint.com. Honestly, I can say with some confidence, Crockford would rather not see our code. ;^) You download JSLint.js (actually webjslint, a minified compilation of a few files) from JSLint.com, but you execute in the browser.
(Admittedly, you're technically right -- you never know when that site could be compromised, and to be completely on the up and up, you sh/c/ould vet jslint.js each time you grab a fresh copy. It is safer to run locally, but as of this writing, you appear safe to use JSLint.com. Just eyeball your favorite browser's Net tab while running some test, non-proprietary code, and see if any phoning happens. Or unplug your box's network cable!)
Rick's answer to use "use strict"; is another great suggestion.
A great way to catch undeclared variables is to add 'use strict' to your code.
The errors will appear in the console, or you could display them in a try ... catch block:
'use strict';
try {
var i= 15;
u= 25;
} catch(ee) {
alert(ee.message);
}
I found a very good solution to list all the global variables with the jsl command line tool:
Here is the documentation
I just have to put /*jsl:option explicit*/ into each file that I want to check. Then it is enough to run ./jsl -process <someFile> | grep 'undeclared identifier'
It is also possible to use referenceFile that contains some intentional global variables /*jsl:import <referenceFile>*/ so these variables will not be listed.
I try to validate some server side javascript with JSHint.
Everything looks great so far, but i got problems with a syntax like this
var foo:type = bar;
The message is
Missing semicolon.
Expected '(end)' and instead saw ':'.
Is there any way to allow it?
JSHint says it is not valid JavaScript, which is true. You can suppress different warnings about coding style, but it does not (and really, should not) allow blatantly wrong code.
Anyway, you should try tslint. It was designed for TypeScript.
We use the Closure Compiler to spot syntax errors in JavaScript and window.onerror to spot all other runtime errors. Every file is augmented with "use strict". None of this catches semicolons that were "helpfully" inserted.
I have tried JSLint, but it has pretty specific ideas about how one should code in JavaScript, and so was less useful than I hoped. For example, with JsLint I can no longer use for (var i = ...) style; JsLint gives up as soon as it encounters one of these.
Is there some other static analysis tool for JavaScript that could warn me about semicolon insertion in particular?
There is also JSHint:
http://www.jshint.com/
You can customize what you want it to warn over. It can be run as a standalone checker as part of your build process, or integrated into various editors.
I have come across JSHint but was hoping it would validate node.js syntax but it doesn't, for example if I do:
var server = http.createServerfunctionThatDoesNotExists(function(request, response) {....
The test passes even though there isn't a function called createServerfunctionThatDoesNotExists
What am I missing with JSHint and the node.js option?
I think it doesn't dig into CommonJS modules as they can contain virtually everything.
So even if you are require'ing http it could be your own module with any interface.
'Assume Node' means it tolerates global variables like module or exports
JSHint is basically JSLint and is more for syntax/style/JS-nonos rather than a deep-scan product that executes your JS. Fully vetting JS code (or any dynamic language, really, depending on your definition of dynamic) pretty much requires running it, since things like methods can be defined more or less anywhere, including at runtime.
JSHint does go a bit further and allow the definition of high-level constructs used by some JS libraries.
I'm getting errors like this using Appcelerator/Javascript:
[WARN] JavaScript compiler reported "'getDefaultServerFromDatabase' was used before it was defined." at includes/server.js:36
I honestly didn't know that was an issue with Javascript. Will it cause problems or is it just good practice? I much prefer to have the main function first in the file then the functions it calls after that. Should I switch this around?
It has not caused any differences in behavior in our application.
The only issue it causes us is to fill up the build screen with those warnings so we may miss important warnings or have to scroll to find compile errors.