The JavaScript Code Quality Tool
See all
Members (644)
Douglas Crockford's profile photo
Madara Uchiha's profile photo
Matthew Heaney's profile photo
Paul Crowder's profile photo
Gaurav Mishra's profile photo
Fredrik Bonander's profile photo
Dulow Kaotic's profile photo
Arvind verma's profile photo
Михаил Шестаков's profile photo
Juliano Lazzarotto's profile photo
Antonio Cunha Santos's profile photo
Usama Ejaz's profile photo
Darrell Little's profile photo
Maulik Gangani's profile photo
Anton Burger's profile photo
John Gillespie's profile photo
Shravan Kumar Kasagoni's profile photo
Jeff Dickens's profile photo
Rahul Sarda's profile photo
Rob Hughes's profile photo
Mariane Machado's profile photo
Mick GRZ's profile photo
Eugenio Gonzato's profile photo
Simon Bruce's profile photo

Stream

Nathan Ho

Discussion  - 
 
It is not possible to break out of array.forEach without using the throw statement, so when a break is needed, we should use array.some or array.every. Which one should we use?

I personally use array.some. I find it more intuitive that 'return true' is a break and 'return false' is a continue, but I would like to hear opposing arguments on this.
3
Jason Kostempski's profile photoPaul Wilkins's profile photo
14 comments
 
+Douglas Crockford This I gather is where we can create our own utility methods to add more flesh to the bones :-)
Add a comment...

Peter Funk

Discussion  - 
 
I understand that multiple assignments within a single var statement can be creating a variable outside the current scope, but why is `a = externalObjects[5].outerComponent[3].config = getConfig(b)` considered bad practice (cause "Unexpected '='.") if `a` helps reduce the number of times `externalObjects[5].outerComponent[3].config` would be used (see example)?

var a,
    b;
...
b = getSettings(things);
...
a = externalObjects[5].outerComponent[3].config = getConfig(b); /* Unexpected '='. */
doStuffWithTitle(a.title);
if (a.idNum > 7) {
    compute(a.myVariable);
} else {
    compute(a.otherVariable);
}
1
Peter Michaux's profile photoDouglas Crockford's profile photo
 
(function () {
'use strict';
function a() {
a();
}
}());
JSLint should warn that a is unused.
1
Douglas Crockford's profile photo
 
Thanks. Please try it now.
Add a comment...
 
A bug with multiline megastrings:
/*jslint es6 */
const multiline = `first line
second line`;
line 2 column 19: Unexpected space between '`' and 'first line second line'.
1
Douglas Crockford's profile photo
 
Thanks. Please try it now.
Add a comment...

Mathias Nater

Discussion  - 
 
I just spent some time tracking a bug regarding property names.
JSLint allows IdentifierName and StringLiteral as property name but complains about NumericLiteral.

var obj = {
one: 'first', //OK
'two': 'second', //OK
'3': 'third', //OK
4: 'fourth' //Expected an identifier and instead saw '4'
};

So far so good.

Now ES6 introduced computed property names. So I can write

var four = '4';

var obj = {
one: 'first', //OK
'two': 'second', //OK
'3': 'third', //OK
[four]: 'fourth' //Expected an identifier and instead saw '['.
};
console.log(obj['4']); //fourth

JSLint obviously doesn't support this bracket-notation, yet. Is it considered harmful?

But that's not the point. I managed to forget the brackets and wrote something like

var one = '1';
var obj = {
one: 'first'
};
console.log(obj['1']); //Expected 'first' but got 'undefined'

So I decided to always use StringLiteral as property name, since at the end it is a string…
IMHO JSLint should warn when IdentifierName is used as property name.
1
Douglas Crockford's profile photoMathias Nater's profile photo
7 comments
 
I don't understand a) and c) without further explanation (I'm not a genius, so you'll have to tell me why I'm wrong…)
I understood b) but I expect from JSLint to make me write quality code – not just fewer bugs.

But I'm again loosing the central theme.

> I'm still convinced JSLint should require quoted property names!

What do you think?
Add a comment...

Douglas Crockford
owner

Discussion  - 
 
JSLint now has a multivar option that tolerates multiple names being declared in a single var, let, or const statement.
7
Daniel Langdon's profile photoR Bailey's profile photo
7 comments
 
@Daniel- It's a complete 180. See 
http://javascript.crockford.com/code.html
... and...
http://stackoverflow.com/questions/34862541/expected-and-instead-saw-jslint-multivar-setting

From the Code Conventions link:

"It is preferred that each variable declarative statement and comment [be on their own line?]. They should be listed in alphabetical order if possible."

... after which the sample is...

    var currentEntry; // currently selected table entry
    var level;        // indentation level
    var size;         // size of table

Note there's a least one sample on the conventions page that doesn't follow this rule, though I assume it's an oversight.

            var array,                // array of class names
                ncn = node.className; // the node's classname

My best guess so far is that it's a sort of extension of, "Each line should contain at most one statement," mentioned on that same page.

But yes, it causes a pretty serious refactoring if you don't use the multivar directive (which wasn't in the repo earlier today, at the least).
Add a comment...

Harry Whitfield

Discussion  - 
 
I have several (old) modules that contain:

Function.prototype.method = function (name, func) {
    this.prototype[name] = func;
    return this;
};

This now produces the error:

Unexpected 'Function'.
Function.prototype.method = function (name, func) {

Is this construct out of fashion, or is it a bug in JSLint?
1
Douglas Crockford's profile photo
 
JSLint doesn't think you ought to be doing that.
Add a comment...

Nathan Ho

Discussion  - 
 
Do you recommend using the maximum line length option?
2
Chris Nielsen's profile photo
 
I'm a big fan of the maximum line length option. It encourages a coding style that puts a single action on a single line (as opposed to chaining many actions on the same line). This makes errors easier to understand, since the line number more accurately identifies the problem.

Also, when comparing changes in a diff, with source control for instance, it is nice to fit two files side-by-side on the same screen without needing to scroll horizontally.

More specifically to me, I have two monitors--one landscape and one portrait. I prefer coding on the portrait orientation, which has less horizontal width.

Finally, you can only read code if you can see it. Needing to scroll horizontally is just painful. Using word-wrap makes things ugly. Well formatted code does not suffer from these problems.
Add a comment...

Mathias Nater

Discussion  - 
 
"JSLint recognizes a small but essential subset of the module syntax." (http://www.jslint.com/help.html#ignore)

Why? Are non-default exports/imports considered bad practice or is it simply not yet implemented?

(I use rollup.js to bundle ES6 modules into a single file.)
How to use JSLint to reduce the rate of error formation in JavaScript programs. JSLint recommends using only the good parts of The ECMAScript Programming Language Standard, Sixth Edition [ES6].
1
Keyamoon M's profile photoDouglas Crockford's profile photo
2 comments
 
I am still waiting for evidence that they are good. Being seen everywhere is not evidence of goodness.
Add a comment...
 
For the code below:
/*jslint node */
'use strict';
function applyTo() {
var args = arguments;
return function (f) {
return f.apply(undefined, args);
};
}
applyTo();

JSLint complains with
Unexpected 'arguments'.
what am I missing?
1
Douglas Crockford's profile photoΝίκος Καλογρίδης's profile photo
9 comments
Add a comment...

About this community

This group is for discussion of JSLint, including feature requests, complaints, update announcements, and testimonials.

Ben Quarmby

Discussion  - 
 
I wasn't happy with the current JSLint plugin for Gulp, so I created my own. Check it out on GitHub / NPM, and let me know what you think.


gulp-byo-jslint - A bring-your-own JSLint plugin for Gulp.
1
Add a comment...

Erwin Zoer

Discussion  - 
 
Just wondering what could possibly be wrong with:

var obviously, wrong;

Result: Expected ';' and instead saw ','.
1
Douglas Crockford's profile photoNathan Ho's profile photo
13 comments
 
+Peter Michaux If you care about file size, use Google Closure Compiler or YUI Compressor. They will automatically reduce such code.
Add a comment...

Peter Michaux

Discussion  - 
 
For the past few years, we've been using JSLint for at least hundreds of browser-bound JavaScript files. It has been very helpful. We keep a local copy of a particular version of JSLint because JSLint has always been a slightly moving target. We can't have JSLint giving worrisome new warnings in the middle of an emergency fix simply because JSLint changed. We upgrade our version of JSLint occasionally.

Sometime recently, JSLint seemed to change its set of options dramatically. We'd like to update to the newest version of JSLint but the options have changed so much that it feels like we cannot. A slightly moving target has been ok but a dramatically moving target is too costly for business. For example, sloppy:true and nomen:true are two options we have on in hundreds of files. It is not a small task to change those files and regression test everything.

Can some of the old options be brought back to help support those who have been committed to using JSLint and have many files to maintain?
5
Paul Wilkins's profile photo
 
It is possible to download those older versions of JSLint so that you can continue testing against them, until time allows for you to improve the code to meet the new standards.
Add a comment...
 
var result = compute(compute(compute(a), b) + compute(compute(c, d)));
Nested function calls impair readability. I wish JSLint would warn on them.
1
Douglas Crockford's profile photoЕвгений Орехов (Evgeny Orekhov)'s profile photo
4 comments
Add a comment...

Keyamoon M

Discussion  - 
 
Any property name with a '$' in it is considered bad by JSLint. It might be helpful to have an option to tolerate that. There is a convention in the Cycle.js community to name streams/observables with a trailing '$'. The argument is that compared to "clickStream", "click$" is shorter and easier to distinguish. Is this a bad convention? JSLint doesn't warn about a trailing '$' in variable names. Why should it be considered bad for property names?
1
Keyamoon M's profile photoBen Quarmby's profile photo
3 comments
 
One of the issues with dangling characters is that their meaning is open to interpretation. To this library a "$" suffix means stream. But I've seen the same character used for promises, jQuery objects or to infer privacy. Angular uses "$" prefixes for "system" unless it's double then it means (faux) "private"... yeah.

Being semantic and avoiding arbitrary meanings for dangling characters reduces confusion.
Add a comment...

Nathan Ho

Discussion  - 
 
Should JSLint's maxlen option only enforce 80-character line length? I don't see the point in giving the programmer freedom to pick any length.
1
Fedge No's profile photoWilliam Chapman's profile photo
6 comments
 
Teams obviously have different needs when it comes to line length.  Therefore, this JSLint feature is fine the way it is.  Since this is a discussion, please state the rationale for the topic statement, "I don't see the point in giving the programmer freedom to pick any length."
Add a comment...

Vitaliy Terziev

Discussion  - 
 
What about auto formatting? It will be awesome not to waste time on empty spaces etc. Maybe the jsbeautifier like engine, is this too hard to implement I wonder.
1
Frank Cedeno's profile photoBen Quarmby's profile photo
5 comments
 
+Frank Cedeno I didn't know that. I must admit I always spread object literals over multiple lines for readability, so it hasn't been a problem.
Add a comment...

Vitaliy Terziev

Discussion  - 
 
Hi Guys,

Nice too meet you all!

I have one question about jslint, why the tool complains when memoization is used, consider the code below and the corresponding jslint error.

Is this a bad practice?
Thank you!

(function () {
'use strict';
foo.baz = true;

function foo() {
var bar = foo.baz;
}
}());

// error
'foo' is out of scope.
foo.baz = true;
JSLint, The JavaScript Code Quality Tool. This file allows JSLint to be run from a web browser. It can accept a source program and analyze it without sending it over the network.
1
黃大衛's profile photoVitaliy Terziev's profile photo
7 comments
 
I see, thanks for the explanation 黃大衛 :)
 ·  Translate
Add a comment...
 
var a = 1 +
2
* 3;
var b = a ===
1
&& a
!== 2;

This is terrible. We should discuss and weigh the pros and cons of placing a break before or after an operator and enforce consistency.
3
Евгений Орехов (Evgeny Orekhov)'s profile photoDouglas Crockford's profile photo
9 comments
 
I don't recommend breaking before or after an operator in most cases. I make use of (
     open
     parenthesized
    expression
). But I am not ready to have JSLint enforce that.
Add a comment...