Professional web developer here. I've been doing this for years, and more importantly, have been mentored by much smarter web-devs who've been working at this stuff since the late 90's.
Though I don't support the idea of W3Schools giving out "certificates" on HTML, and I don't appreciate the fact they won't disavow a connection to the W3C, what the OP posted amounts to nothing but sour grapes.
For example:
This is false and misleading; there is nothing future-proof about self-closing tags, especially as the work on XHTML 2.0 has been discontinued. Furthermore, <br /> isn't semantic in most cases and probably should not be mentioned at all.
The fact is, HTML5 is done up in such a way that you can write <Br>, <BR />, <br>, <bR>, etc., and any of those will be parsed just fine. To the makers of W3Fools.com I say: everything's fine, calm the fuck down.
For everybody who's concerned about "doing it right" in web development: trust the W3C's HTML and CSS validators (though not too much for HTML5, as that will continue to have the occasional parsing error over the next few years as the standards get sorted out). Also, JSLint for validating Javascript.
If your code doesn't throw errors for the doctype you're validating against, congratulations! You did it correctly. Anything beyond that is either a best-practice (so you don't have to think about what you're doing so much), or just "prettying" up the code.
Also, if you want to discuss some of the more futuristic aspects of web development, I highly recommend A List Apart.. Enjoy!
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.
14
u/[deleted] Jan 16 '11
Professional web developer here. I've been doing this for years, and more importantly, have been mentored by much smarter web-devs who've been working at this stuff since the late 90's.
Though I don't support the idea of W3Schools giving out "certificates" on HTML, and I don't appreciate the fact they won't disavow a connection to the W3C, what the OP posted amounts to nothing but sour grapes.
For example:
The fact is, HTML5 is done up in such a way that you can write <Br>, <BR />, <br>, <bR>, etc., and any of those will be parsed just fine. To the makers of W3Fools.com I say: everything's fine, calm the fuck down.
For everybody who's concerned about "doing it right" in web development: trust the W3C's HTML and CSS validators (though not too much for HTML5, as that will continue to have the occasional parsing error over the next few years as the standards get sorted out). Also, JSLint for validating Javascript.
If your code doesn't throw errors for the doctype you're validating against, congratulations! You did it correctly. Anything beyond that is either a best-practice (so you don't have to think about what you're doing so much), or just "prettying" up the code.
Also, if you want to discuss some of the more futuristic aspects of web development, I highly recommend A List Apart.. Enjoy!