No, really. Think this is intentional? I mean, you'd think the Chrome developers know what JSLint is. You'd think maybe they could sneak in an exception for it...

 

Labels: chrome, JSLint

From Jslint Is Not A Code Quality Tool For 3rd Party Code – Hugh FD Jackson:

Crockford is an opinionated, experienced and charismatic guy. As such people often do, he has gained significant influence. In this post, I’m going to focus on what Crockford thinks the role of JSLint is, as typified by this suggestion:

“There is one reliable, objective metric of JavaScript code quality that can help you in making your choice [… of library …]: JSLint. If JSLint finds problems in a library, then dump it and move on to the next one.”

I firmly believe that this attitude is damaging; and worth focusing on given his potential influence.

Yeah, wow, no. That is bad advice.

As I've said on Stack Overflow before:

As a rule, you should exempt 3rd party libraries from your linting. There's nothing you can do about external libraries unless you want to fork them and lint them yourself, which is, well, insane. ;^) And, again, minified code often takes shortcuts that aren't lint-friendly.

Lint your code before you minify to keep its quality high, but don't worry about QAing libraries you shouldn't be touching anyhow. Assume they have another method for ensuring high quality, which might include using a different linter, or a linter with a different set of rules.

I'm a huge fan of linting your JavaScript code, and there's no more thorough linter for less investment on your part than JSLint. Nothing it forces you do is objectively wrong, and you don't have to worry about getting everyone in a room to set up an ESLint rule set before you get started.

But there's absolutely no reason not to use libraries that aren't themselves lintable in their original. There's a clear interface between you and that code. It's sort of like how RMS wishes you wouldn't use any non-GNU code. A proscription from using non-JSLinted libs is more political than rational.

Labels: code, crockford, ESLint, JSLint, style

Saw a question on StackOverflow this morning that mentioned ESLint was merging with another JavaScript linter, JSCS, or at least their teams were.

I added a quick comment:

An opinion question as written (the one you link to does a good job hitting a grey area: "Show me the way code is handled differently in each"), but here's an interesting, related tidbit: It appears ESLint isn't merging with so much as aqui-volunteering (?) JSCS's team.

... the first goal of the combined ESLint/JSCS team is to make the transition to ESLint easy for JSCS users.

They've planned to add features from JSCS that ESLint doesn't have now, but it seems the JSCS codebase isn't merging with ESLint, but is likely going to wither on the vine. Makes sense, but still interesting!

_{Aside: I like aqui-volunteering. See what I did there? (Sorry.)}

One comment from the ESLint project's announcement about the merger bugged me, however...

With the new combined ESLint/JSCS team, you can expect a lot more from ESLint in the future. We now have some of the brightest people in the world working on making ESLint the best possible tool for JavaScript syntax analysis. I’m personally very excited about ESLint’s future and tackling some of the more difficult problems like making autofix possible for every rule and incorporating type information into our analysis. We can go a lot further, faster, when we’re all working on the same tool. [emph mine]

Ah, the mythical volunteer month strikes again. If only all that were true.

I still don't know what more coders really buys you. If you take the time to create clearly defined interfaces between every chunk of work, you can gain nearly 2x production from double the coders. And I think there's something to careful use of pair programming, which provides three sets of advantages:

1. Great architectural review.
2. Bug spotting that ids lots of low-hanging fruit/duh moments.
3. Shared familiarity with code.

The third is one of the most important. Forcing coders to share what they were doing and thinking with someone else gives you the first and second, but also means that your cyborg -- and all code is full of cyborgs, some strange melding of code and the style of the person(s) writing it -- is more spread out, reducing the impact whenever some of the meatware decides to move on.

But does it work here?

But when it comes to great JavaScript linting, I'm not sure more is better. You've still got one guy working on a linter as a side project that, afaict, is every bit as useful, if not moreso, in standardizing code and enforcing best practices than the work of the 371 (to date) at ESLint. (In case you're new to the blog, that's JSLint.)

I mean, tell me which code you'd rather maintain:

or...

And I should point out the JSLint repo has no folders, and you really only need that single jslint.js file. Occam's code, folk. Make code so simple to use that it'd make William proud. ;^)

I like Nicholas at ESLint. Seems like a really good guy -- and ESLint seems like a good, well thought-out tool. It just seems like overkill -- harder to maintain, more to learn to use proficiently, more likely to change from installation to installation, which means less standardized code -- and there's nothing that bugs me like over-engineering. One example: Autofixing? Why not just use Typescript from the start? Seems too much for a linter. Teach me how to write good code. Don't automate the fishing.

Here's a less biased example: Looks how excited this guy on SO is that ESLint makes it exceptionally easy to create new rules.. To me, that's cringeworthy -- No, no no, I don't want everyone on the team creating new rules! But if quickly creating custom rules is your use case, well, ESLint might be what you're looking to find.

(Though, admittedly, I have suggested to others that they hack JSLint directly, since it's just JavaScript, which might be even worse.)

Anyhow, just an interesting [to me] cultural contrast between two popular and useful linting projects.

Labels: coding, cyborg, ESLint, JSLint, style

Yay?

I guess I could do something like add ESLint to the list of alternatives to JSLint on the JSLint tag wiki, but that's not that horribly exciting.

The next priv on SO is "Access to Moderator Tools", which actually is awfully powerful. I would've never thought I'd make it there, but with the way points from old answers keep coming in like dividends from old investments, I guess it could happen.

And I can't help myself. 5000 came from another JSLint answer -- one I posted yesterday. I'm always surprised at the amount of venom JSLint gets on SO. There's almost always a stupid an ill-advised comment about how horrible JSLint is, and how the asker should use ESLint or JSHint instead, for many questions with the JSLint tag. Yesterday's was no exception.

Within a few minutes of the question's posting, there's that second comment...

I'd strongly recommend finding an alternative to JSLint, and it's outright silly rules warning about perfectly valid JavaScript. Consider ESLint, JSCS, or even JSHint.

... and it's got four votes. So five people have complained about the topic of the question within a few minutes of its posting, and rewarded pretty inflammatory, off-topic speech. So I finally did it; I replied too harshly.

Good heavens. Sorry to vent on you on this question, but if it's a JSLint question, give a JSLint answer. I don't spam up the ESLint & JSHint questions with, "You really should take out all of your dimestore opinions about JavaScript and use a linter with strong opinions to more universally standardize your codebase." Commenting "your tool stink0rz" is like saying, "Stop using JavaScript. VBScript rulez!1!" It's just opinion. Crockford's rarely demonstrably wrong; often, folks who make these comments don't take the time to understand what he recommends or why.

The implicit VBScript comparison might have been too much. ;^) I'm sure JSHint & ESLint are good tools. I've followed both a bit and used JSHint for a while, and they're fine, if you want lots of room for customization... and intra-office debate.

Painfully, I replied twice, ending with, "Show me where JSLint "actively harms Javacript" & I'll show you someone who doesn't understand the lang," which I'd still stand behind, I think. You can disagree with JSLint, and it will, famously, hurt your feelings, but it's almost never wrong in any definitive way.

Okay, actually I ended with...

/sigh I'm ending this transmission. (The irony, of course, is that I think krillgar's found a bug in the new JSLint.)

Always makes a quick exchange more fun when you can drag in Thumb Wars.

Still, I just don't get it. Is there another tool that gets this much flame? Honestly, I really do believe one of JSLint's strengths is, as I've mentioned, that you precisely don't have to get together as a committee every time someone wants to change some minor piece of JavaScript coding style. Crockford's not dumb, and, again, his prescriptions (well, proscriptions) are very rarely, if ever, wrong. And if it's wrong, he'll fix the code quickly, as I've seen a number of times (and even been a part of once or twice).

Why is more opinion always better? I hate JSLint's whitespace rules, particularly with hanging lines and end parens, but say what you want, at least it's an ethos.

WARNING: Some NSFW language here:

Often, it's lazy to decide for yourself instead of figuring out why a convention suggested by an expert might be smart.

I'm also much happier looking at JSLint's code. Have you looked at ESLint's repo? I mean, nothing wrong with it, but it sure isn't a single file. Looks like it's a node-directed solution too. Why must tools become so complicated so quickly? (I know Nicholas wanted "a JavaScript tool with pluggable linting rules", but I'm not sure all the overhead is necessary.)

Anyhow, there's nothing wrong with JSLint. If it doesn't work for you, I'm sorry. But when a JSLint user has a JSLint question, give them a JSLint answer. If you've got to throw in a, "But I usually use ESLint or JSHint," that's fine, but answer the question first.

/rant

Labels: coding, gamification, JSLint, stackoverflow, style

Labels: coding, goals, JSLint, stackoverflow, style

So my JSLint plugin of choice for Sublime Text got a bee in its bonnet and updated JSLint.js today. Apparently, Sublime Text 2 package control automatically updates plugins by default, because my code went crazy after a reboot.

And this is why I say "bee in the bonnet"; it's not like the plugin has been particularly good about updating JSLint as it's updated. Out of the blue, WHAM.

There's a setting to turn autoupdate off, even one (auto_upgrade_ignore) to just ignore nasty, GOT YA!! plugins like this one. ;^D

So my settings got blown away today (okay, fine, the edits should've been in my user pref file, but sometimes that file doesn't seem to take for some plugins), and JSLint got upgraded to Crockford's ES6 "friendly" version that hates this and for. Most folks I work with aren't ready for all that just yet, and I don't have the fortitude to argue they should go bleeding edge and use it. I mean, it's fighting just to get the old version of JSLint used on projects...

Luckily there's a good backup of the plugins sitting in a folder (for me, it's C:\Users\YourUserNameHere\AppData\Roaming\Sublime Text 2) waiting on me, so I'm a auto_upgrade_ignore setting and copy and paste away from being back at work.

UPDATE: I did a better job explaining this over on the plugin's Github Issues page, though the issue title is admittedly a little over the top. ;^) Luckily, I seem to have captured the feeling of a few other users... I'll paste that here.

A few important tips, I guess, if you want to do this without bothering with gitting...

• See the auto_upgrade_ignore option for the Sublime Text package manager.
• Add JSLint to auto_upgrade_ignore in Preferences >>> Settings -- User (see below, though I haven't tested it yet).
• Quit Sublime Text 2
• Blast (delete) your current JSLint package folder.
  • (on Windows, that's likely C:\Users\YourUserNameHere\AppData\Roaming\Sublime Text 2\Packages)
• Head to your ST backups folder to get the old plugin
  • (on Windows, that's likely C:\Users\YourUserNameHere\AppData\Roaming\Sublime Text 2\Backup)
• Grab the one with the JSLint folder in it that's closest to the date of the change.
• Copy and paste the JSLint folder from your backups folder into your packages folder.

So, for instance, my Preferences.sublime-settings file currently has:

{
    "auto_upgrade_ignore":
    [
        "JSLint"
    ],
    "color_scheme": "Packages/Color Scheme - Default/Mac Classic.tmTheme",
    "draw_white_space": "all",
    "font_face": "ProFontWindows",
    "font_size": 9,
    "ignored_packages":
    [
    ],
    "translate_tabs_to_spaces": true,
    "trim_trailing_white_space_on_save": true
}

If I fall into a lot of spare time, maybe I'll fork this and let you chose a specific jslint file, though I had some trouble dropping an old jslint.js file directly into C:\Users\YourUserNameHere\AppData\Roaming\Sublime Text 2\Packages\JSLint for some reason, iirc.

Labels: JSLint, sublime text

I recently bumped into @slicknet, a developer for Box who maintains the ESLint project. Here's a quote from ESLint's About page:

The primary reason ESLint was created was to allow developers to create their own linting rules. ESLint is designed to have all rules completely pluggable. The default rules are written just like any plugin rules would be. They can all follow the same pattern, both for the rules themselves as well as tests. While ESLint will ship with some built-in rules to make it useful from the start, you'll be able to dynamically load rules at any point in time.

Here's a good example of when open, pluggable architectures are bad news, and why benevolent dictatorships might still be the best mode of governance.

Questions to ask before deciding on your own linting rules:

1. How many people do you know really know their JavaScript?
2. What percentage of devs at a non-Node shop might those folks represent?
3. How diluted will their voices become when your company decides JS best practices in a committee?
4. Will those rules that your company comes up with really be better than rules from Douglas Crockford?
5. How long did it take for you to come up with those inferior rules?
6. How much time will it take to discuss making changes to those rules in the future?

Answers:

1. Three. Maybe three and a half.
2. Ten percent. If you're lucky.
3. Significantly.
4. No.
5. Hours on hours X number of developers in the meetings.
6. Please, stop it already. You're killing me.

Technically speaking, of course open, pluggable architectures are superior. But in this case, culturally, it's a huge mistake.

Maybe Box's tech stack includes Node, where it's much harder to hide only so-so JavaScript skills, and maybe, in that environment, the openness of ESLint allows them to create something that's no worse than JSLint. But show me one place where JSLint's rules are demonstrably worse than your own (where they can't be turned off with directives) before you argue for ESLint or JSHint.

(That's not to say I don't think ESLint is cool, or that a pluggable interface isn't technically superior to what JSLint offers. But now take your time from questions 5. and 6., and add an obviously smart dude's time maintaining this project. If he's doing it on his own clock, well, more power to you. It's fun to [re]create these sorts of projects, and there's no way to understand a problem better than to live in a "meta-project" like this. My guess is that Mr. Zakas knows his stuff (if I really knew him, I'd have to change #2 to "4-4.5" Or I'd keep it the same, and take myself out). If he's doing it "at work", however, we might have a priorities problem.)

Labels: business, JSLint, priorities

I wanted to see if JSHint had a provision for checking imported packages for property names in a file it was, um, "hint"ing, and ran into a link to the, "Why I forked JSLint" post (which was down -- domain now points to github? -- but lives at archive.org) again. The post is interesting. The representative example given to fork JSLint is a horrible one, imo. Kovalyov argues that he should be able to put a var before a iterator variable, like this...

for ( var name in obj ) { ...

That's really not a good reason to leave JSLint. Forcing you to acknowledge variable hoisting doesn't seem that objectionable. There are other things that it forces you to do that I don't see as much wisdom in, but this really isn't one of them. And that his snippet has "Example taken from jQuery 1.4.2 source" as if that made it automatically something worth emulating also gnaws at my craw a bit.

But the post's epigraph from Crockford does resonate:

Your sadly pathetic bleatings are harshing my mellow. —Douglas Crockford.

Wow. Reminds me of the link I use in my StackOverflow profile to undercut where I quote, "You should take JSLint's advice," a bit. The guy's a great coder, and I enjoy his very strict approach to JavaScript 99.44% of the time, but Kovalyov is right: Crockford's social skills (and, from what I've seen, hubris) are awful.

But again, bad social skills don't make the tool just as toxic. Kovalyov links to Brenan Eich, "creator of JavaScript", where Eich says, "JS Lint can suck it" That's said, sure (Eich is using automatic semicolon insertion, though he's doing it to make his code look like CoffeeScript, so Kovalyov has already taken the quote well out of context), but there's an interesting counterpoint Kovalyov misses in that same blog post from Eich:

Here's my pitch: committees do not design well, period. Given a solid design, a committee with fundamental disagreements can stall or eviscerate that design out of conservatism or just nay-saying, until the proposal is hardly worth the trouble. At best, the language grows larger more quickly, with conservative add-ons instead of holistic rethinkings.

What I like most about JSLint is that I know I'm getting similar code across the board. JSLint honestly enforces well-considered conventions. When Kovalyov says, "It is quickly transforming from a tool that helps developers to prevent bugs to a tool that makes sure you write your code like Douglas Crockford," my reply would be, "And you think your committee is going to do better?"

So many questions about JSLint on StackOverflow get answered with, "You should use JSHint." But if we all use JSHint to turn off whatever bugs us, as we'd do if we followed that advice each time, what do we leave turned on? Just the things that aren't troublesome? Isn't our code getting lint-i-er each time? Show me an example of where what Crockford requires from you is wrong -- not just annoying, but undeniably worse than an alternative. I don't think it exists, yet.

Isn't the point of a linter to challenge us all to write better code?

Labels: coding, culture, JSLint, style

Here's the easy version. I'm not sure how well the formatting will keep with this email-to-blog post, but hopefully I'll eventually remember to return and clean it up.

So save the below into index.html and knock yourself out. No jQuery or nuttin required.

Gosh, I hope this post works. HTML always worries me with Blogger. It's anyone's guess how it'll parse it this week.

<html>
    <head>
        <script src="jslint.js"></script>

        <script>
            function jslintalizeMe()
            {
                var i, divOut, errs, errsMsg = "";

                divOut = document.getElementById("errors");
                divOut.innerHTML = "";

                if (!JSLINT(document.forms[0].elements[0].value))
                {
                    errs = JSLINT.errors;
                    for (i=0; i < errs.length; i++)
                    {
                        err = errs[i];
                        if (null !== err)
                        {
                            if (undefined !== err.id)
                            {
                                errsMsg += "Error: " 
                                + err.code 
                                + " -- line " 
                                + err.line 
                                + " char " 
                                + err.character + "<br />"
                                + "    " 
                                + err.evidence + "<br />"
                                + "    " +
                                 err.reason + "<br /><br />\n";
                            }
                            else
                            {
                                errsMsg += err.reason;
                            }
                        }
                    }
                    divOut.innerHTML = errsMsg;
                }
            }
        </script>

    </head>

    <body>

        <form>
            <textarea rows="24" cols="80"
                placeholder="// Paste quality code here"></textarea>
            <br />
            <button onclick="jslintalizeMe();return false;">JSLint</button>
        </form>

        <div id="errors"></div>
    </body>
</html>

Labels: javascript, JSLint

Good grief folks, can we roll back to the old pyra editor?  I've put the following text into the HTML pane:

filter.first.first.id === '.' &&
filter.first.first.first.first &&
filter.first.first.first.first.string === 'Object' &&

and when I look back in the Compose pane, the &'s from the html are turned into &.  Should the code be &?  Yes.  Should the HTML display in the Compose window be & (with code of &)?  Good heavens no.

Look, I appreciate the work, but between the BlogThis formatting trouble and the "quirks" in the edit page, it's getting close to time to leave blogger (I've been blogging here since 2001).  I spend more time formatting than writing.

Labels: blogger, google fail, JSLint

Additionally, parseInt and make different assumptions about the radix when there’s a leading zero. ”012″ returns 12, but parseInt(”012″) returns 10. The leading zero causes parseInt to treat it as an octal number in probably all browsers, despite octals being summarily deprecated in ES3. Of course, you can use parseInt(”012″,10) to get around that.

Labels: javascript, JSLint

Re: Does a global variable exist? < Prev Next >
Posted By:douglascrock...

Wed Jul 8, 2009 7:02 pm |
...
this.hasOwnProperty(name)

Labels: javascript, JSLint, noteToSelf

You can set any of jslint's options under preference -> package settings -> jslint -> advanced built settings. See http://www.jslint.com/lint.html#options for a list of options in JSLint. There's no move_var option (that's just a label for an error condition), but you can use the vars: true option to permit many variable declarations per function.

 {
    "cmd": [
      "node", 
      "${packages}/JSLint/linter.js",
      // sloppy line breaking?

      // tolerate dangling _ in identifiers
      "--nomen",
      // tolerate ++ and --
      "--plusplus",
      // tolerate missing 'use strict' pragma
      "--sloppy",
      // sloppy whitespace
      "--white",

      // assume a browser,
      "--browser",

      // suggest an indent level of ...
      "--indent", "4",
      // assume node.js to predefine node globals
      "--node",

      // tolerate unfiltered for in
      //"--forin",

      // tolerate stupidity
      "--stupid",

      // tolerate todo
      "--todo",

      // anon whitespace okay 
      //"--anon",

      "--maxerr","6",

      "$file"
    ],
    "file_regex": "^\\/.*\\/([^\\/]*)$",
    "line_regex": ".*\/\/ Line ([0-9]*), Pos ([0-9]*)$",
    "selector": "source.js, source.css, source.json, source.sass, source.less, source.html"
}

Labels: JSLint, sublime text

This is a java wrapper around the fabulous tool by Douglas Crockford, jslint. It provides a simple interface for detecting potential problems in JavaScript code.

Labels: java, JSLint, noteToSelf

This section provides documentation to get quickly started to embed and run Javascript .NET in your application.

Labels: Google, javascript, JSLint, visual studio

In few words, as I have said already before, null is == only with null and undefined, which means we can avoid completely redundant code such:

// Mr D way
if (v !== null && v !== undefined) {
    // v is not null neither undefined
}

// thanks JavaScript
if (v != null) {
    // v is not null neither undefined
}

Labels: javascript, JSLint

All code in any code-base should look like a single person typed it, no matter how many people contributed.

Labels: coding, javascript, JSLint

I’m not sure what specs you were looking at but ECMAScript defines the following syntax:

if ( Expression ) Statement else Statement
if ( Expression ) Statement

{…} (a block) is technically a statement in itself (a statement that contains statements). I tend to use blocks because, oddly, I find them more readable.

if (!already)
    var itemInit = ctrlr._getItemInit(which);
if (itemInit)
    // some lines snipped
    itemInit.call(ctrlr, root, doneMap);

Labels: JSLint

The place to express yourself in programming is in the quality of your ideas, and the efficiency of execution. The role of style is the same as in literature. A great writer doesn't express himself by putting the spaces before his commas instead of after, or by putting extra spaces inside his parentheses. A great writer will slavishly conform to some rules of style, and that in no way constrains his power to express himself creatively. See for example William Strunk's The Elements of Style [http://www.crockford.com/wrrrld/style.html].

In criticizing The Elements of Style, Geoffrey Pullum, professor of linguistics at Edinburgh University, and co-author of The Cambridge Grammar of the English Language (2002), said that:

The book's toxic mix of purism, atavism, and personal eccentricity is not underpinned by a proper grounding in English grammar. It is often so misguided that the authors appear not to notice their own egregious flouting of its own rules . . . It's sad. Several generations of college students learned their grammar from the uninformed bossiness of Strunk and White, and the result is a nation of educated people who know they feel vaguely anxious and insecure whenever they write however or than me or was or which, but can't tell you why.[10]

Labels: coding, communication, javascript, JSLint

... I get an additional error stating Unexpected space before '['.

The only way to get rid of this error is to format the script like this, which I think make it more unreadable:

var showOrHide = 'show';
jQuery('.selector')
 .removeAttr('style')[showOrHide]();

So my question is would it be possible to make the second example not produce an error?

Thanks :)

Labels: communication, crockford, JSLint