creationix (Tim Caswell)

I see this argument was already had elsewhere, but John Resig put an end to it. I respect John and Douglass Crockford, they've done a lot of good for JavaScript. I will comment no more as I now see this is simply flame bait. I apologize I didn't see sooner. http://github.com/jquery/jquery/commit/ddb86f8d5bd1bd21b2beeeea55baf505b47dfed5#comments

Ok, so to get back to my original point. Joshaven uses JSLint to clean up code. We've discussed this with Ryan quite a while ago, and he's fine with using it to clean up node's internal code. The official code conventions for node are posted at http://wiki.github.com/ry/node/contributing. While it doesn't specifically require semicolons, it does mention the other fixes that Ryan got straight from JSLint from what I presented to him.

I don't understand where all the hostility is coming from. It's just a simple fact that these are the conventions for node, and Joshaven't commit was accepted by Ry and pushed into the main code. I don't see why the big fuss.

I'm not saying that anyone is evil for not putting semicolons in their javascript. They were made optional intentionally so that it's easier for beginners to learn the language. I'm just saying that it's better for us that know better to follow the grammar and not rely on hacks that were added into the language to help beginners. There are dangerous situations where it guesses wrong. While these situations happen a little less in a controlled environment like node, they still happen.

Also, as far as the technicality of my statement. From the spec:

"..is also not a valid ECMAScript sentence, but is transformed by automatic semicolon insertion into.."

Or in other words, the code missing semicolons does not follow the grammer, and so the pre-parser/parser tries to fix it. If the parser actually fixes the code in one pass or does it in a separate pre-parser pass doesn't matter. The point is that code missing semicolons is invalid and must be repaired before it can be executed. Either we can do the work and explicitly put the semicolons where we meant for them to go, or we can trust in the implementation to do the right thing. Since the spec tells implementations to basically "If you see an error, than back up and add a semicolon to see if it fixes the error", I don't trust it one bit.

You're welcome to do whatever style helps bring beautiful code to pass, but don't accuse others of being nazis for not trusting this terrible algorithm to insert the required semicolons for us.

@raggi, The language does have a standard, it's terrible and specifies that the parsers implement these crazy rules. If you understood the history of JavaScript and how it was never really thought through or designed it would make sense.

Ryan has made it clear that he wants to use vanilla V8 Javascript, I think that's a good idea. The V8 guys have made it clear that they want to keep in sync with JavaScriptCore, and so basically, not following the spec, or even patching bugs in V8, if there were any, is not the place of node.

And to clear up what I mean by the spec specifying the crazy whitespace sensitive rules, here is the relevant part of the official spec.

https://gist.github.com/4658280967e5a1fba668

Basically it says that semicolons ARE NOT optional to be valid code, but parsers are required to implement a pre-parser that tries to guess where to put the semicolons. Hence, omitting them is both dangerous and slows down the parser because it has to "repair" your code first.

I coded for years in other languages with braces on new-lines instead of at the end of the line like is common in JS. When I started doing heavy javascript work I forced myself to switch to the new style. At first it felt ugly and wrong, but then with time I learned to actually prefer it.

I believe that it is good to like how the code you write looks, but it's perfectly possible to train our eyes to "like" something that follows conventions.

Besides, most everything in the Crockfordian conventions has technical roots, not based on taste or preference. Half those technical reasons aren't valid in the world of node, but it's common to write client-side code too on a node project and there it does matter.

It's just a matter of taste, I prefer to use the same style on both sides if possible. Also after many large JS projects, I've learned to like and enjoy the conventions. They are beautiful to me and I'd guess to many others.

@brianmario: innovation is awesome.

I agree that the conventions are a bit strict and verbose, but that makes it easiest to understand for most people.

Javascript is a verbose language, get used to it. I think consistency is what matters most when talking about code conventions. Doug's stuff is good enough, especially if you know when to break the rules. I think it's a good idea for Node's core javascript to follow a common convention. And the widely accepted, and strict conventions from Doug are probably a good way to go. We can of course adjust and ignore the stuff that doesn't apply to us since we're not in the browser.

Also assignment expressions can be dangerous even though they're clever and concise. I know from personal experience. People aren't used to looking for side effects in expressions. Use them when it's best to do so. There are cases when using a with statement is the only way to accomplish something. It's fine to break the rules in these cases, but being sloppy about braces and semicolons just because it makes your code a few characters shorter isn't a good idea.

If it were just conventions, I might agree, but it's more. While those semicolons and braces on line ends are optional sometimes, this isn't always the case. Remembering the cases where they are needed and where they aren't needed can be terribly confusing. Not to mention that this changes a little across implementations.

Saying that JSLint is a crutch that keeps us from learning the language means you completely miss the point of JSLint. You shouldn't take any advice from the program unless you understand why it's telling you to do something. There are cases where some of the suggestions are wrong. It's a tool for people who do understand the language.

If you really learned and understood the language, you would understand why most of the JSLint "best practices" really matter. Sometimes Douglass Crockford goes a little too far towards strictness. JavaScript as a whole isn't that good a language, but there is a subset of it that's really nice and reliable. These best practices help up stick to that good subset.

Besides, I use JSLint.org to check my code, and it helps find real bugs as well as petty formatting issues. It reduces the noise of the error report if you go ahead and follow the formatting rules. JavaScript is a very misunderstood language. For example, the rule in JSLint that says that only one var statement is allowed in a function seemed silly at first to me. Then after debugging some nasty issue in my TopCloud framework for a week, I found it was related to having a var statement late in a function body. JSLint would have saved me a week of pain and suffering.

Because that's the accepted JavaScript best practice. Sure it doesn't matter since V8 has good and reliable parser, but when doing client side work, they're essential. Especially for IE. It's just easier to keep the same strict style everywhere.

Ok, I merged in the changes from express. I like the new separation of concerns better. Also I tagged it as the first stable release.

Agreed, I think I'll change it to not do any file/io but simply take in text and output text.