Glad it inspired you!

Given the enormous research and tests done on a vast amount of developers, the result has been that two of the most common roots of problems are omitting semi-colons, and not using braces for one-line if statements.

You can do whatever you want, but out of responsibility to the people paying for your code, and for the developers that will take over it, I think it’s a good idea to pay heed to the advice in various linting tools.

Similarly, I simply smile when folks get tense about the absence of braces in code snippets like this:

if (condition)
one line of code;
else
other line of code;

sitting all by itself with one line of white space above and below.

You folks have fun arguing about braces and semicolons, I’ve got some code to write.

Freddie Mack
dopey box loses indents – I leave them to you

Yeah, with proper options specified, I think I can support that initiative then.

Andrew,

Yes, I know about it, but at the end, it’s just about what options to specify. Meaning, I use the increment approach and JSLint, and we get along fine.

Thanks for the tip, though!

Steven,

Well, you don’t have to, if you’re careful. But personally, I’d just recommend it.

It’s actually quite an interesting debate on placement of curly braces.

On one hand, it does seem to improve readability for nested statements, but on the other hand it also increases the amount of “blank” lines in your code. This secondary effect means that you will be able to see less of your code on the screen at any given moment, which means a whole lot more scrolling.

I know that Microsoft advocates “opening brace on new line” for C#, which might give the impression that it is common or even considered good practice. I am sure that there are other vendors that also advocate this practice, so for once I am not bashing MS

But, once you get comfortable with a language, you should be able to read indented statements easily, regardless of placement of braces, and the value of using newlines for opening braces is greatly diminished. For JavaScript it can be fatal, and I expect that other languages like ActionScript would suffer the same fate.

It is my experience that you get the better code quality by assuming some level of skill by the reader, rather than writing code that is readable to newcomers of the particular language… they’ll get the hang of it soon anyway.

Thanks.

Robert, you might consider JavaScript Lint in favor of JSLint. I used to whole heartedly stand by JSLint, but more and more it seemed like Douglas Crockford either making a point or being strict beyond the point of practicality. For example, in for loop declarations, JSLint will throw an error for using the increment operator. Crockford has a valid reason for this: it’s hard to read code like i + --i, and without the spaces this would cause problems. However, even when you’re just incrementing your loop variable, if you use the normal settings on JSLint, it will throw an error for using i++. JavaScript Lint is a bit more sensible about this in that the increment operator is valid so long as you’re not combining it with other operators.

It is possible to pass options to the lint, to tell it what to bitch about, and what not… but I do see your point, and some of the “complaints” might not be obvious for the less experienced JavaScript programmer… and this will just increase frustration without necessarily increasing quality of code.

But then again, I hate warnings (or broken windows) as much as the next developer, so if I am Lead, you’re just going to have to deal with the harsh rules

Yes, I know that you prefer that style (I don’t).

But also, there are JavaScript approaches, such as the Yahoo Javascript Module Pattern, which relies on returning an object.

Besides, someone like you know the ins and outs of JavaScript, so you when things will break and when not. My take is that most people don’t, so personally, I’d recommend using the opening curly bracket on the same line as the code.

Morgan,

Well, maybe. JSLint is very good overall, but it might complain about something which you’d deliberately want that way, and it feels a bit counter-effective to demand JSLint validation in those cases.

Perhaps I should just expand that to run my stuff through jsLint as well.

Great, thanks!

Morgan,

Thanks for the tip! Personally, I use that bundle in TextMate, and it sure saves me some problems at least.

icaaq,

Absolutely!

http://github.com/subtleGradient/javascript-tools.tmbundle/tree/master

It’s called JavaScript Tools, was originally written by Andrew Dupont, and has since been adopted and moved to bundleforge.

http://bundleforge.com/

For me, the most interesting feature of the bundle is that it runs your javascript through jsLint every time you save the files.

That will give you immediate feedback on bad coding style, missing semicolons, etc.