Hacker News Reader

Comment by mradmin | Hacker News Reader

Yup, for example: https://github.com/koajs/koa/blob/master/lib/application.js#...

A similar convention, often seen within the node community: https://npmjs.org/doc/coding-style.html#Comma-First Personally, I find this ugly with very little benefit. It seems awkward to edit.

Agreed, I follow this styleguide: https://github.com/felixge/node-style-guide

Comma first is a great convention, it allows you to easily comment out an item in a list while debugging. for example:

  var test = [
              "firstitem"
              , "seconditem"
              //, "thriditem_commented_out"
              //,  "fourthitem_should_also_be_commented_out"
           ]

Otherwise you have to do this:

  var test = [
               "firstitem",
               "seconditem"//,
               //"thriditem",
               //"fourthitem"
           ]

It's just a lot more cognitive overhead to not put the comma first.

That's not true because the spec for JS allows the trailing comma. IE is the only browser that doesn't follow this. So if you are doing Node dev, the trailing comma is harmless.

You realise it's the opposite for the first item, right? Code easier to read (and thus understand) is what everyone should aim for.

I did this for a while, it's easier to spot missing commas and allows you to comment out lines (besides the first line) but I switched back because it was annoying to align :/

But you do know why this style exists and what benefits it has?

I don't, and I'd be really grateful if anyone would enlighten me on the matter. Please excuse my ignorance!

If you forget to type a 2nd '=', putting a constant as the left-hand-side will allow the runtime to error instead of treating the expression like an accidental assignment with potentially disastrous side-effects.

In some languages sometimes but in general I think that's the use case for yoda code.

it goes back further than this..

in compiled languages it is a compile time error. So you don't run through 1/2 of your application before you run into it. Instead it shows up as soon as you run make/gcc/g++/etc.

Wikipedia gives an explanation: http://en.wikipedia.org/wiki/Yoda_conditions Seems kind of meh, especially if you're writing javascript when keywords like undefined can be redefined with no effect.

Hmm, I've read reasons why you could code like this, but personally I would never make my code more complicated to read just to prevent errors that I can prevent with other methods, like having tests, for example. I would assume after someone has been coding for a decent amount of time, they would have the experience to spot declaration/assignment mistakes and shouldn't have to rely on yoda conditionals to prevent this. Perhaps there's other reasons I'm not aware of, and am not seeing the light because of that, care to share your thoughts?

I adopted this in my C days. Sure some compilers catch accidental assignment but not all and it could be disabled. As a defensive programming style I personally think the readability concerns were outweighed by the safety benefits. Not everyone agrees and I adapt my style to the project I'm working on.

In most environments, writing something like `if (x = 5)` will generate a warning.

E.g. if you use JSHint, you'd get:

"Expected a conditional expression and instead saw an assignment."

Nowadays, there usually isn't any benefit in using yoda conditions.

It does seem strange, is there a reasoned argument for why this can be better?

The two reasons I've heard are preventing accidental variable assignment and preventing null references. Personally, I don't think either of those things outweigh the readability issue.

Reply on news.ycombinator.com