Browse files


1 parent 8c7bdd8 commit f819cf3c65d07086cf217c549c577fa77dc65fc9 Douglas Crockford committed Dec 14, 2012
Showing with 8 additions and 9 deletions.
  1. +8 βˆ’9 jslint.js
@@ -1,5 +1,5 @@
// jslint.js
-// 2012-12-04
+// 2012-12-14
// Copyright (c) 2002 Douglas Crockford (
@@ -272,7 +272,7 @@
'margin-left', 'margin-right', 'margin-top', mark, 'marker-offset', match,
'max-height', 'max-width', maxerr, maxlen, menu, message, meta, meter,
'min-height', 'min-width', missing_a, missing_a_after_b, missing_option,
- missing_property, missing_space_a_b, missing_url, missing_use_strict, mixed,
+ missing_property, missing_space_a_b, missing_url, missing_use_strict,
mm, mode, move_invocation, move_var, n, name, name_function, nav,
nested_comment, newcap, node, noframes, nomen, noscript, not,
not_a_constructor, not_a_defined, not_a_function, not_a_label, not_a_scope,
@@ -301,8 +301,8 @@
unexpected_typeof_a, 'unicode-bidi', unnecessary_initialize,
unnecessary_use, unparam, unreachable_a_b, unrecognized_style_attribute_a,
unrecognized_tag_a, unsafe, unused, url, urls, use_array, use_braces,
- use_charAt, use_object, use_or, use_param, used_before_a, var, var_a_not,
- vars, 'vertical-align', video, visibility, was, weird_assignment,
+ use_charAt, use_object, use_or, use_param, use_spaces, used_before_a, var,
+ var_a_not, vars, 'vertical-align', video, visibility, was, weird_assignment,
weird_condition, weird_new, weird_program, weird_relation, weird_ternary,
white, 'white-space', width, windows, 'word-spacing', 'word-wrap', wrap,
wrap_immediate, wrap_regexp, write_is_wrong, writeable, 'z-index'
@@ -542,7 +542,6 @@ var JSLINT = (function () {
missing_space_a_b: "Missing space between '{a}' and '{b}'.",
missing_url: "Missing url.",
missing_use_strict: "Missing 'use strict' statement.",
- mixed: "Mixed spaces and tabs.",
move_invocation: "Move the invocation into the parens that " +
"contain the function.",
move_var: "Move 'var' declarations to the top of the function.",
@@ -605,6 +604,7 @@ var JSLINT = (function () {
use_object: "Use the object literal notation {}.",
use_or: "Use the || operator.",
use_param: "Use a named parameter.",
+ use_spaces: "Use spaces, not tabs.",
used_before_a: "'{a}' was used before it was defined.",
var_a_not: "Variable {a} was not declared correctly.",
weird_assignment: "Weird assignment.",
@@ -1195,11 +1195,10 @@ var JSLINT = (function () {
character = 1;
source_row = lines[line];
line += 1;
- at = \t/);
+ at =\t/);
if (at >= 0) {
- warn_at('mixed', line, at + 1);
+ warn_at('use_spaces', line, at + 1);
foaly-nr1 Dec 20, 2012

should be at least an option!

foaly-nr1 Dec 20, 2012

great! sorry, didn't see it!

nix1 May 21, 2013

'White' ('messy white space') ignores the indentation entirely, so it's not the same as 'mixed spaces and tabs'.
Looks like you can't check if your code is formatted properly if you use tabs for indentation, I definitely agree that it should be an option!

Zorgatone Feb 18, 2015

I REALLY want to check messy space but having an option to ALLOW TABS instead of spaces.
It's really annoying I can't check that without replacing all my tabs (and i want those in my project).
I believe that spaces are messy, especially when copy/pasting the code indentation will be ugly

73rhodes Oct 16, 2015

It's safe to assume tabs can and usually do look messy to everyone who isn't you viewing the file in your editor of choice. So, πŸ‘Ž to tabs. But forcing a 4-space indentation is πŸ’©

Zorgatone via email Oct 16, 2015
- source_row = source_row.replace(/\t/g, tab);
at =;
if (at >= 0) {
warn_at('unsafe', line, at);
@@ -6449,7 +6448,7 @@ klass: do {
itself.jslint = itself;
- itself.edition = '2012-12-04';
+ itself.edition = '2012-12-14';
return itself;

32 comments on commit f819cf3


@Zorgatone "especially when copy/pasting the code indentation will be ugly" - How?


@Zorgatone If you had an argument that made sense I would consider it.


I am sorry if I can't explain it well. Maybe it'll be more clear with an example.

I'm used to indent my code with tabs because I think it suits me more. When I said that copy/pasting with spaces could be messy I was referring at the fact that someone could use a different number of spaces per indentation level. That is why I prefer tabs, but this is not the problem with the tool now, it is just why I would love to have the option to choose to indent with tabs, and not being forced to use space.

I know the text editors can be set up to enter spaces instead of real tabs, but I personally do not like that option. I use real tabs otherwise the editor allows me to accidentally delete some and place the caret beetween indentation levels.

My actual problem with JSLint itself, is that I have to change all my indentations, just to test if I styled my code correctly (ie. the space in "function () {...}" beetween the word 'function' and the parenthesis).

If I have tabs in my code instead of spaces, and I use the option white: true, JSLint won't complain about the tabs, but it won't check the space beetween statements and identifiers (see the example below with the function).

I don't want to bother anybody, I don't know how much work it would take to implement such a feature.


You can't explain it well because there is not a clear advantage to using tabs over spaces or vice versa, except for one: There is a universally accepted standard for how many spaces a space occupies. There isn't such a standard for tabs. We should pick one because having to choose between two is a waste of time, and there can be interoperability hazards. So we go with spaces. Get used to it.

Krinkle commented on f819cf3 Mar 4, 2015

There is little value in arguing over indentation. It makes sense for a style guide to pick one and enforce it universally (as opposed to merely enforcing consistency within a file). It always surprised me that JSLint/Crockford hadn't yet "officially" specified one. Most other style guides (such as jQuery) have long documented theirs.

There's no rush in upgrading your copy of JSHint, though. (If re-indenting large projects isn't at the top of your priority list.)

For what its worth, there are alternatives. For example, one could decouple coding style from code quality (by using JSLint with white: false, or use JSHint). Perhaps use a separate tool for enforcing a style guide of choosing. JSCS, for instance, even ships with a crockford preset. You could extend it with your own rules, or modify existing ones (e.g. validateIndentation: "\t").


@douglascrockford for the company that I work with interoperatbility is not a concern. We all use the same code style. In my (our) opinion a tab character more clearly communicates the intention: I want to indent by one, whereas 4 spaces only have that meaning when they occur together.

We have worked hard to attain great control over how we develop software, to avoid interoperability (and other) issues. I would like a tool that respects this effort.

Is this argument enough to consider adding an option to switch between spaces or tabs? - as opposed to disabling indentation checking altogether.

I suppose it's good to see that even to this day JSLint hurts my feelings :) It feels like progress.


No, it is not. I recommend that you take JSLint's advice.

webdif commented on f819cf3 Nov 20, 2015

For the sake of separation of concerns, tabs is the way to go. When you want to indent, you don't want a tab, two spaces or four spaces. You just want an indentation. The look of this indentation should not depend of the content.

Using spaces instead of tabs seems like using a style attribute in HTML tag instead of using a separate stylesheet, really.


The problem is not whether you want to use spaces or tabs (because that's a religious war you're never going to win). The problem is unilaterally introducing an arbitrary whitespace dogma that isn't backwards compatible, removes a much-used config param, and breaks everyone's CI process. @douglascrockford


"breaks everyone's CI process".

That sounds serious. Can you document that everyone's CI process has in fact been broken?


I had one project that was affected, but to be more accurate, upgrading would break a CI process that includes jslint and enforces whitespace with the earlier configurable option set to something other than 4-spaces. My main concern is issues raised by users of, where the upgrade affects the workflow in their dev toolchain.


@73rhodes That does not sound like jslint broke your CI process at all.

nix1 commented on f819cf3 Nov 24, 2015

@73rhodes Why won't you switch to another tool then? jshint, jscs, eslint... they're all configurable :)


@73rhodes It sounds like you have updated a tool you use, with that you have choosen a new coding standard, but you did not update your codebase to follow that. It sounds like you broke your code, and in it current state it cannot pass the code validator version you have choosen.


One of the complicating factors is that jslint doesn't have great versioning... just a date. It's not easy to know if an upgrade is going to obviate an established precedent and suddenly invalidate your code. If it was versioned you could at least lock down dependencies more easily. @nix1 that could be the solution.


The obvious solution is to fix your code. It isn't that hard. There are tools that will do it for you. You could have accomplished that in less time than it takes to complain that you think you shouldn't have to.


@73rhodes "It's not easy to know if an upgrade is going to obviate an established precedent and suddenly invalidate your code."

Seems easy to me. For each new version you test it out, and if it doesn't work you fix it.


@douglascrockford yeah, enforcing 4-space indentation is a great way to increase code quality. Next step, remove all options for jslint, hard-code your style and make everyone follow your taste. It should make everyone code's better than before.


@donnykurnia Hard-coded style is exactly one of the core ideas of JSLint. From the README: "Conforming to a consistent style improves readability, and frees you to express yourself in ways that matter. JSLint here plays the part of a stern but benevolent editor, helping you to get the style right so that you can focus your creative energy where it is most needed."

It would be counter to this philosophy to provide options allowing you to enforce your own custom style. JSHint/ESLint/JSCS allow you to do that. JSLint instead makes all of its users stick to a single style. I agree with JSLint's stance. In my opinion, there is no value in having more than one coding style.


@backseatviolist yup. And the beauty of the free software is that I have another options. All my code have 2 spaces indentation and there are forks of JSLint that still read the indent option. I have freedom to determine how many spaces for indentation in my code, and only need the lint to show me actual errors instead of telling me that 2 spaces indentation is an error that must be corrected.


You are mistaken in thinking that your freedom is of greater value than the benefits obtained by conformance to good standards.

If you will present me with convincing data that your way is significantly, measurably better in enhancing readability or reducing error formation, then I will immediately repair JSLint to conform to that better style. That is what I have been doing since the JSLint project started.


Two arguments. 1) Different people prefer different visual indentation; some like two spaces, some like four, etc. If everyone uses tabs, they can set their editors to whatever they like to see, but all code looks good everywhere. 2) if you're moving a block of code in (a very common operation), it's only one delete keystroke rather than two or four.


Preference is not a reliable source when designing a style.

Optimization of keystrokes is the wrong thing to be optimizing. You should instead focus on error avoidance. You spend much more time making, finding, and correcting errors than you spend typing.


Good point on 'optimization of keystrokes' not being as important as error avoidance. You are correct.

But on the first point, developers absolutely have different ways of working, and different editors. Code indentation is a precise part of good code, and tabs allow precision with developer flexibility.

p.s. Thanks for js ,and JSON, and your great book.


Not wanting to pick a fight, but TABs create smaller file sizes:


And as @larboyer said if we use TABs people can set what they want to see on their editor of choise


@larboyer I was talking about network requests sizes.... not hard drive space...


@larboyer If you use a good editor, there is no difference between spaces and tabs. Most of them support deleting multiple spaces as one. Also, minification is a requirement for any large project where network usage matters, regardless the tab space debate.


@larboyer Try to use shift + TAB to unindent.

Please sign in to comment.