Commit
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,5 @@ | ||
| // jslint.js | ||
| // 2012-12-14 | ||
|
|
||
| // Copyright (c) 2002 Douglas Crockford (www.JSLint.com) | ||
|
|
||
|
|
@@ -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, | ||
| 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, 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.", | ||
| 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 = source_row.search(/\t/); | ||
| if (at >= 0) { | ||
| warn_at('use_spaces', line, at + 1); | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong. 
nix1
|
||
| } | ||
| at = source_row.search(cx); | ||
| if (at >= 0) { | ||
| warn_at('unsafe', line, at); | ||
|
|
@@ -6449,7 +6448,7 @@ klass: do { | |
|
|
||
| itself.jslint = itself; | ||
|
|
||
| itself.edition = '2012-12-14'; | ||
|
|
||
| return itself; | ||
| }()); | ||
32 comments
on commit f819cf3
There was a problem hiding this comment.
@Zorgatone "especially when copy/pasting the code indentation will be ugly" - How?
There was a problem hiding this comment.
@Zorgatone If you had an argument that made sense I would consider it.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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").
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
No, it is not. I recommend that you take JSLint's advice.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
"breaks everyone's CI process".
That sounds serious. Can you document that everyone's CI process has in fact been broken?
There was a problem hiding this comment.
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 https://github.com/73rhodes/Sublime-JSLint, where the upgrade affects the workflow in their dev toolchain.
There was a problem hiding this comment.
@73rhodes That does not sound like jslint broke your CI process at all.
There was a problem hiding this comment.
@73rhodes Why won't you switch to another tool then? jshint, jscs, eslint... they're all configurable :)
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
There was a problem hiding this comment.
@larboyer I was talking about network requests sizes.... not hard drive space...
There was a problem hiding this comment.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@larboyer Try to use shift + TAB to unindent.
There was a problem hiding this comment.
should be at least an option!