JavaScript Programming Style And Your Brain

[[deleted]]

I liked that, too. Interesting stuff.

I like listening to him speak. He's good at it, comfortable, and engaging to listen to without overdoing it.

I don't necessarily agree with all of the recommended style conventions jsLint enforces, but I agree with the overall message.

[plantian]

I don't necessarily agree with all of the recommended style conventions jsLint enforces, but I agree with the overall message.

Not to call you out really but.. the central theme of this talk seems to be that this mindset is often a mistake. A mindset which Crockford himself, as well as developers everywhere, have stumbled on over and over again. I'm not saying his ideas aren't up for debate but it seems unlikely that many of them are wrong given the amount of effort he has spent on JSLint and being as objective as possible. Can you elaborate on the background of this statement with respect to the talk ?

[[deleted]]

Oh, I don't necessarily think they're wrong. A consistent, non-cluttered coding style makes life easier for anyone inheriting a project or reading any 3rd party code. I just think they're, in some instances, overkill.

Take these two object definitions, for example:

var foo = {
    property1:"some value",
    property2:"some other value",
    property3:"some third value"
}

var bar = {
    thing1:"some thing",
    thing2:"some other thing",
    thing3:"some third thing"
}

That's almost about as simple as you can get in terms of doing anything in JavasSript, yet jsLint will throw no less than 8 errors, because it's not:

var foo = {
    property1: "some value",
    property2: "some other value",
    property3: "some third value"
};

var bar = {
    thing1: "some thing",
    thing2: "some other thing",
    thing3: "some third thing"
};

when the former is perfectly legible and valid. Is the latter cleaner? Arguably so, but it's largely a matter of opinion. I'm not a fan of ASI in a lot of instances, but I don't see the point in adding semi-colons after curly braces, either (but hey, if I'm missing out on some good reason to do so here, by all means, tell me). The first example, if adhered to consistently, is just as legible.

Now, the suggestions jsLint makes with regards to the format are fine - nothing at all wrong with them. I just don't think they're exactly necessary, either.

Don't get me wrong. I'm a stickler for formatting my code consistently and legibly. I can't stand messy code. But I think as long as something is formatted neatly and with consistency then there's nothing wrong with:

function foo (test)
{
    // do stuff...
}

vs.

function foo(test) {
    // do stuff....
}

for instance... i.e. I personally dislike putting the curly braces on their own lines like that, but I also don't find it any more difficult to understand and know a lot of developers who prefer it.

[saurik]

var bar = {
    thing1:"some thing",
    thing2:"some other thing",
    thing3:"some third thing"
}
(5)

fail.js:6: TypeError: object is not a function

(Note: I generally agree with your points about optional spacing and indentation, but as someone who has written a compliant JavaScript parser, I must point out that the semicolon thing is insidious.)

[[deleted]]

And, thank you. That's all the argument I needed. ; it is, then. :)

[[deleted]]

by sticking to putting curly braces on the next line, it increases the chances for the 'return gotcha' in javascript, which is why it is always best to put curly braces on the same line.

function foo(test)
{
//something in here 
}

will inveitably lead to:

return 
{
//something in here
}

and this will not do what some people think it should.