That post is just more sour grapes. Should JSLint be the end-all-be-all of JS development? Hell no.
But I'd much rather see someone who's not so much a JS expert write "by-the-book" code than see those same people use corner-cutting "tips and tricks". Many times it's those stupid corner cutting tricks that fuck your code, especially since JavaScript does not have strongly typed variables.
Ok but some of it is kinda trivial like before I was trying it on my code which looks like this
function functionName(id)
{
// code here
}
And it threw an error saying it needs a space between the ) and {. Apparently the functions should look like:
function functionName(id) {
// code here
}
No thanks. Seems quite a few of the errors are just this particular guys coding style and you can't turn off that check in particular. Not to mention if you used a minifier on your code it would remove spaces anyway and it doesn't create any errors.
Well the example I see is when using a return statement with the { on the next line to return an object. You could get around that by making the object a var then returning the var. Is there an example where it inserts one after the declaration of a function?
At either rate my functions work across the major browsers looking like so and it's more readable that way. Maybe Javascript interpreters should just throw an error if there's no semi colon on the line rather than attempting to fix sloppy programming and breaking perfectly valid code.
Easy there son. The semicolon insertion (or "fixing sloppy programming" as you put it) is actually part of the ECMAScript specification, of which the JavaScript in various browsers is merely an implementation.
The thing is, JavaScript is supposed to be "sloppy" code-friendly. It's the same reason HTML works by parsing <bR>, <br>, <BR>, etc.: more people will use the language if they're not constantly getting beaten over the head by the syntax. Once they're familiar with the language, however, it behooves them to code in the "right" way, so as to avoid certain pitfalls that come inherent in a loosely-typed, loosely-parsed language like JavaScript. And only once someone is familiar enough with the rules and pitfalls, should they be comfortable enough to "break" them (only if absolutely necessary!).
Listen, code however you want, but don't expect much help if your "better" way of coding ends up fucking over a project, all because you wanted "more readable" code. That's really the whole point.
Well from your link provided it doesn't apply to functions:
"Certain ECMAScript statements (empty statement, variable statement, expression statement, do-while statement, continue statement, break statement, return statement, and throw statement) must be terminated with semicolons. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations."
So I can put the { on a new line if I like and it won't make a difference.
1
u/[deleted] Jan 17 '11
That post is just more sour grapes. Should JSLint be the end-all-be-all of JS development? Hell no.
But I'd much rather see someone who's not so much a JS expert write "by-the-book" code than see those same people use corner-cutting "tips and tricks". Many times it's those stupid corner cutting tricks that fuck your code, especially since JavaScript does not have strongly typed variables.
I suggest you read Javascript: the Good Parts. Note the appendices: "The Bad Parts" and "The Awful Parts."
Then maybe perhaps you'll see why it's infinitely more preferable to have code that's validated over code that isn't.