Hacker News Reader

Comment by camus2 | Hacker News Reader

If TJ is on board that's the only information you need to know, you cant go wrong with any code that guy writes.

I often purposefully avoid TJ modules because many of them end up being unmaintained. Before using a TJ project check the outstanding pull requests: are there a large number of open useful looking PR's? Is there somebody besides TJ merging into master: aka has he delegated a maintainer?

if there's a project you want to maintain for him, just ask and he'll give you ownership. i help with koa and most of his more popular repos have multiple maintainers now, so don't worry.

Ryan left node a long time ago, people still use it, just because the original author isn't involved doesn't make it a bad project

That's right. I don't really care if you're actively involved in the project; I just want somebody you trust to be. Like any node shop we quite happily use a bunch of TJ modules.

There were a few of his projects going this way but he recently reached out for maintainers[1] and things are looking better now.

[1] https://medium.com/code-adventures/c819768a175f

I have utmost respect for TJ and his work but I am not a fan of his yoda style programming :(

What do you mean by that? if (constant == variable) type conditions?

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

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.

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.

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 :/

haha I've grown to prefer it, sort of like regular conditionals vs postfix conditionals, you set up the expectation first:

if (user.isAuthenticated) doSomething()

doSomething() if (user.isAuthenticated)

the first is less readable perhaps but I think it's more useful for a programmer. To each their own! Maybe some day I'll be convinced otherwise, I like it better for asserts too:

assert(200 = res.statusCode) assert('application/json' == res.headers['content-type'])

assert(res.headers['content-type'] == 'application/json')

looks weird to me now but maybe I'm just used to it

Reply on news.ycombinator.com