jshint / jshint Goto Github PK

JSHint error messages make repeated incorrect usage of the term "function statement" in lieu of FunctionDeclaration. While extensions exist in Mozillas' implementation, there is no standard function statement. ECMAScript has FunctionDeclaration and FunctionExpression. The wording of error messages should be changed. For example:

Input:
if(1) {
function a(){}
}

Result: Failed.
Function statements should not be placed in blocks. Use a function expression or move the statement to the top of the outer function.

The error message is misleading or wrong. There is no "outer function" in the example and ECMAScript has no "function statement." Instead, the error message should read:

Function declarations are not Statements; they may never appear in blocks. See also: FAQ: What is a function statement? and Named Function Expressions.

Show the options string either by adding it to the beginning of the code or directly below.

I see you support rhino related globals. https://github.com/jshint/jshint/blob/master/jshint.js#L346

Would be great to see the same for node.js

can I hide "mixed space and tabs in line ..." errors/warnings. Output from this warning annoys me. This should be completely configurable.

Maybe it's already possible with classic jslint. If so, please close this issue.

JSHint does not allow many ExpressionStatement as Program code. All literals result in error:

1;
true
"blah";
null;
/a/;

JSHint Result:
Expected an assignment or function call and instead saw an expression.

The expected result should be no error. These are all valid Programs.

A Literal is an PrimaryExpression which is an Expression. A program can have ExpressionStatements.

ExpressionStatement :See 12.4
    [lookahead ∉ {{, function}] Expression ; 

Literal ::
    NullLiteral
    BooleanLiteral
    NumericLiteral
    StringLiteral 

PrimaryExpression : See 11.1
    this
    Identifier
    Literal
    ArrayLiteral
    ObjectLiteral
    ( Expression ) 

Error in ES3 spec omitted RegularExpressionLiteral from list of Literal; that too is valid.

The following code should at the very least have an option to be allowed without throwing the error:

object && object.method && object.method();

or
variable && func(variable);

paste {a:"b"}, it says "Expected a string and instead saw a." at the same time paste alert({a:"b"}.a); it says "The code check passed."

mbulman@9991adf

JSHint doesn't like the destructuring assignment, but rhino likes it just fine ;)

Is there a better way to contribute? Or does this work?

The idea is to allow people to specify options unique to the current function scope. For example:

// You cannot use eval here

(function () {
    /*jshint evil: true */
    // You can use eval only inside this function scope.
}());

// You cannot use eval here

(function() {
    // ...
    test();

    function test() {
    }
})();

Errors with:

Line 3 test();
'test' is not defined

This is extremely pedantic, I would expect such behavior from Lint, but Hint? ;)

THe operators typeof and delete accept a reference. If, during evaluation, the base object of that reference is null, the result is not a runtime error.

These operators were designed to fail safely without error. However JSHint prevents such acceptable usage in the following.

JSHint Inputs:
typeof f;
delete f;

Results: failed.
'f' is not defined.

The above inputs are perfectly valid and the program can be evaluated and run without error. JSHint should not result in error here.

Hi,

Definitely love the project idea. :-)

Some points about jslint I find annoying:

1. "Expected a 'break' statement before 'default'."

Ex:

case 'help':
default:
    // print help
}

I realized I could remove the 'help' case and always go to default, though I kept it for readability. Ironically, if you do remove it, you get this lint error (another I ask to consider):

1. "This 'switch' should be an 'if'."

This has been plaguing me since the dawn of time. Specially when I prefer the readability of a switch structure vs if/else (ex. cli parsing)

Cheers,

Right now, JSHint prohibits re-definition of globals:

/*global JSHINT: false */
JSHINT = {}; // error: read only

If you try to add var to it then the error is about variable being redefined. Should we remove the read only error or make it that there is no redefined error when variable is in /*global */?

Getting this firebug error:

error is null
"');}return __;"    jquery.tmpl.js (line 358)

with the following code:

(function($){
 alert('hiya');
})(jQuery);

All options checked except "Tolerate eval" and only "browser" for environment.

Automatic semicolon insertion is all scary until you actually understand it, then it stops being scary. This tool needs an option to turn off missing semicolon checks for people who decided to go semicolon-less.

I thought that the line breaks option affects this, but apparently it doesn't (at least not in the browser).

Example:

$.each(list, function(index, value) {
    if (!value) {
        return true;
    }
});

jshint cannot parse

new Array(1);

the error is: Expected ')' but instead saw '1'. Missing semicolon

I use this pattern (a lot):

function test(foo) {
    var foo = foo || false;
}

This triggers an error. I'd like to be able to "shadow" variables, and turn this checking off in an option (JSure allows this).

Consider this contrived snippet from a method in an object literal:

draw: function(flag) {
    var flag = flag || false;

    inner();

    function inner() {
        console.log("Ellipse.draw()");
    }
}

This throws a jshint error, namely, using inner before its declaration. Technically, there is no error in JavaScript in this case, and it is very often convenient to put all of the "flow" for the parent function up top, with the inner functions declared blow (instead of the other way round). This is a feature, not a bug. :) Would remove this error case entirely since it's not an error, or make it an option you can turn on.

Enough said. Editing each and every js file just doesn't cut it.

I'd love to see an option to assume jQuery (or another library using $) is available.

Chances are good that code being run through JSHint might use the $ function that has been defined in another file somewhere, and it would be nice to have it as an option to turn off the errors from $ being undefined.

for (var i=0; i < 10; i++) {}
returns:

Line 1
this is undefined

imho, it's perfectly valid JavaScript.
Rewriting it to the following makes the message go away:

var i;
for (i=0; i < 10; i++) {}

The following input is valid and should not result in error. Yet JSHint calls it a fail.

a();
function a(){}

if(!b) {
var b = 1;
}

Result: failed.
'a' is not defined.

Even when unchecked "Require variables to be declared before usage", the result is still an error.

The first is not an error; a is defined and is available to be called. The second is not an error because during lexical mode if b is not a global property, then it is created and given value undefined. Then, when Statements are evaluated, the if(!b) is evalueated as false and b is given value 1.

I think JSHint should not

I had to write this because of very long case/break , for using folding functions of my editor (kde4 enviro):

switch (variable)
{
case condition1 :
{
[... 412 lines]
}
break;

case condition2 :
{
    [... 96 lines]
}
break;

}

this lead to :

Line ### : {
Expected to see a statement and instead saw a block.

It has been expressed on Anton Kovalyov's blog by more than one person that the negative views towards Douglas Crockford on jshint.com and on Anton's blog post are not necessary and more importantly not a reflection of the views and opinions of the JavaScript community as a whole.

If this fork really is about listening to the community then can we not change the paragraph regarding the differences between it and jslint to be a little more positive about your new direction/ideas and not so derogatory towards another.

I've been experimenting with C-style "namespacing" in a couple of my frameworks, in particular, Jo. For example: joView, joContainer, joControl are all global widget classes. Since they are global, I do not need to specify var = joView, and so I prefer to save a good chunk of unzipped file size (it's a small framework).

I can solve this with the global flag, and that's cool, but I'd like to be able to specify something like:

/*jshint */
/*global jo*:true */

(function(window, undefined) {
    // ...
})(window);

Errors with:

Line 1 (function(window, undefined) {
Expected an identifier and instead saw 'undefined' (a reserved word).

This is a widely used and good pattern, not only does it protect against overridden undefined it also allows for better minification since undefined can be reduced to a single letter name.

like "HTML5" technos as fileReader, localStorage ,
or any predefined libs like fck, tinymce, jquery, mootools, ..

It will permit to keep an easy way to test something not previously hardcoded in jshint

Here's a quick list I've compiled:

emit, log, getRow, start, send, require, but there are a couple more. I'll try to dig them up.

like the title says, I would love to see a Memory Leak detection option to help optimize any/all JS code

JShint fails to parse

function foo() {
var x;
return x = 12;
}

if breaks on the return statement with the error:

Missing semicolon. Expected an identifier but instead saw '='

à la https://gist.github.com/357981

!=== is mentioned on jshint.com; of course, this is invalid JavaScript, and should be !==.

there are a number of options that help you with the layout and spacing of your code but it seems that there is no option that will warn of trailing whitespace.

I had to add exports.JSLINT = JSLINT; to the end of fulljslint.js so that I could use it in tests but really it's not a way to go.

Related commit: 506e46b

jshint.com is a parody I guess, but its error message are ACTUALLY USEFUL >|

PS, just kidding, this would be fun to have though

In fact, it is a very fast and succinct way of testing whether something is 'undefined or null'. Suggesting that I replace it with === null is bogus.

Hi all,

Seeing that nodejs support is out of the box, I had a craving to create a cli for jshint and published it as an npm package (called node-hint). It's pretty much like nodelint (https://github.com/tav/nodelint)

https://github.com/brentlintner/node-hint

It still needs a bit of work/refactoring and more tests (hacked it), but it (seemingly) works overall. I was not sure if anyone else was working on the same thing, so I wanted to mention it on here, in case the community finds it useful or even forkable.

Cheers,

PS, the website rocks \m/

new FunctionExpresssion ; Results in Error.

new function() {
this.name = "";
};

Result:
Weird construction. Delete 'new'.

This is not an error. The advice to "Delete 'new'" results in significantly changed program behavior. I would like to see JSHint allow this valid production, no warning, no error.

Crockford made an update: jslint-org/jslint@dedfd85

It seems like nobody uses ADSafe so I don't think that JSHint should have it as a dependency.

This code is perfectly sane, but not accepted :

var intwolines = 'Here we have a very long string, and for lisibility,
i use a break inside';

Incorrectly return three errors :

• Bad escapement.
• Unclosed string.
• Stopping, unable to continue.

I asked to have it in support in JSLint, Crawford responded me : « This is bad practice ».
I'm not sure having a very long line of 4000 chars is a better way, neither having
var =''
+''
+''
.....

One of things I've never been able to convince Crockford of is to allow case statement fallthroughs.

Currently, this is okay:

switch(foo){
case 1:
case 2:
doSomething();
}

But this is not:

switch(foo){
case 1:
doSomethingFirst();
case 2:
doSomething();
}

In a version of JSLint that I hacked before, I made a check for a comment /falls through/ to indication that you intend to fall through:

switch(foo){
case 1:
doSomethingFirst();
/falls through/
case 2:
doSomething();
}

I'd really like to see this included in JSHint, as it's been a pain in JSLint for a very long time for me.

One other area that JSLint still lacks is better integration with build systems like Maven. The common current solution is to wrap the Rhino call as a giant XML blob. A more elegant solution would be to load via a native Maven plugin.

I may look into this soon as it is a current need of mine, but if anyone else feels ambitious this would be a huge win for JSHint build-time integration.

phase 0

• rename branches.
• basic readme
  • purpose
  • compatible with command-line linting, of course
  • encourage issues to be filed with biggest jslint gripes

phase 1

• get hosting (something with a nice post-commit hook)
• redirect domain

I'm using quotation marks instead of dot notation so Google Closure Compiler knows not to rename the keys when using advanced optimizations. Please let us turn this notice off.

Raw HTML is harder to parse.

I have several patterns where, for looks, I'll repeat a variable definition. One is

if (compatiblilityTest)
  var someOperation = function(){"The standard way";};
else
  var someOperation = function(){"The IE way";}

The other is multiple loops in a function all defining their i counter with var. Of course, if the loops are nested, this'll trip you up, but it would also trip you up if you didn't use var on the second loop.

Suggestion: Expose white space and indentation checking options, to allow customisation of which rules are applied when "apply strict whitespace rules" is chosen. This would allow white space checks to be more useful in places with different coding standards.

Having the white space rule set is very helpful for projects with many developers, to highlight and encourage coding standards. However, under JSLint (like many of its features), the option is a boolean black box where you either apply the JSLint way or turn it off.

For example, the Switch statement is commonly used in two forms, depending on what coding standards a company may have chosen to adopt:

// Java coding standards indent (and JSLint)

switch (foo) {
case "bar":
    break;
case "baz":
    break;
default:
    break;
}

// Alternative (and common) indentation style

switch (foo) {
    case "bar":
        break;
    case "baz":
        break;
    default:
        break;
}

If you are in an environment where the latter standard is in place, the white space check becomes unusable because it will always fail on switch indentation, and therefore the only choice is to disable it completely, even though the rest of the white space checks may be useful and desired by the team.

Other examples of "whitespace" rules I think would have value being exposed as options are the ones dealing with anonymous functions:

function() {} // common
function () {} // crockford

(function (){})() // common
(function (){}()) // crockford

And paren spacing:

if ( something ) { 
if (something) {

Being able to turn "use whitespace checking" on, but have the ability to configure what whitespace checking "means" for your particular use case, dev standards and work environment would be very helpful in JSHint being a usable style checking tool for improved code quality.

Dummy configuration example:

var whiteSpaceSettings = {
    switchIndent: false,
    anonFnSpace: false,
    anonFnWrap: false,
    parenSpace: true
}

Good luck with the project, I think there's a lot of value in a community driven version of JSLint.

Ian

Like this:

var blah = {
a: 'b'
, b: 'c'
};

Unless there is a good reason why that's bad (I'm interested to know).

The benefit of it is that it keeps you from ever accidentally having a trailing comma when you delete the last item from an array/object:

var blah = {
a: 'b',
b: 'c',
};