Last weekend, I decided to try adding JSLint to my JavaScript editor’s workflow.
For those not familiar, JSLint is like that elementary school teacher who enjoyed using their red pen just a little too much when they graded your essays. Except JSLint doesn’t care about mismatched verb tenses or dangling participles– it cares about things like undeclared variables, consistent space indentations and unexpected ‘++’ usage.
I should mention, the creator of JSLint (Douglas Crockford) boasts his program will hurt your feelings. And he’s absolutely right.
Every time I saved my file, I had lines of red text in a pane in the bottom of my code editor window, chiding me for the bad habits and short cuts I’d taken in my coding. I was particularly irked when it complained about an “insecure ‘^'” in my regular expression because I was specifically using that negation character to eliminate unwanted non-alpha characters.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| // before | |
| phrase = phrase.replace(/[^a-zA-Z]/g, ""); | |
| // after | |
| phrase = phrase.match(/[a-zA-Z]/g); | |
| phrase = phrase.toString(); | |
| phrase = phrase.replace(/[,]/g, ""); |
I considered disabling that particular option in JSLint, but I really wanted to be able to say my code passed JSLint on its default configurations. So I eventually found a different approach to my regex about which JSLint wouldn’t complain.
But here’s the funny part– days later, I find this specific incident has me looking at regexs differently. I’m consciously looking for that negation caret in my daily coding, all because of this run-in I’ve had with JSLint.
Which leads me to this conclusion: The real point of JSLint is to improve the author, not the JavaScript code.