Hacker News Reader

Comment by MattBearman | Hacker News Reader

Love this one:

  return foo == null ? null : foo;

View on HN

I don't think people tend to write this kind of code, per se.

Rather, it "evolves".

It starts as:

  return foo == null ? error_handler(bar) : foo;

And someone realizes error_handler actually does nothing, so replaces all calls with null, mechanically.

Exactly.

The same is probably true for this one here:

public bool ShowOptional() { bool bolReturn = false;

    return bolReturn;

}

There should be descriptions why the code snippets are supposed to be interesting, your and my example just look like legacy code to me.

This is often the case. When implementing something complex, a train of thought may require writing code then reducing it down to a degenerate form once certain conditions are confirmed/discovered; often the degenerate form is left as a placeholder in case something need be added back in ... alas, the final cleanup stage may not arrive and some oddities may be left behind to confuse future maintainers. Cleverness can, from some angles, look stupid.

Or maybe it's just stupid.

Sometimes you just can't tell the difference.

That one makes a bit of sense in Javascript as it'd return null if foo was null OR undefined.

It might be technically correct, but if the intention was a loose comparison surely don't include null in the comparison?

  return !foo ? null : foo;

... or

  return foo || null;

if you're into that sort of thing

This reminds me of this one, which is quite common:

   return foo == null ? true : false;

It's better than

    return foo ? true : false;

or even

    return foo == true ? true : false;

So transposing a boolean into a boolean is better than transposing a truthy value of an unspecified type into a boolean?

You are missing the point, which is it's really silly to transpose a boolean into a boolean using a ternary operator.

If you want to argue that "foo == null" is the problem due implicit nil value falseness, than the solution is simply to use strict comparison operator "===", transposing "foo == null" into a boolean doesn't solve the falseness issue if you think this is what the original author was trying to address.

I sometimes do that in PHP because I hate the equivalence between "", false, null, '0' and 0. Seeing true and false written out makes it more readable.

would a comment not be more appropriate in such circumstances?

The result of "foo == null" (or better "foo === null") is boolean, I don't know what is the "equivalence" problem here.

Maybe this is a programmer who likes to spell things out for future readers. It's easier to convey meaning with return foo == null ? true : false;

Let's picture a future reader:

"Hmmm, if 'foo == null' is true, than it's true... I see..."

Seriously..

From a maintenance perspective, it's a bit more involved than that. Returning the explicit evaluation result says, "I do care what foo is and these are the only valid possible return values after expression evaluation, today just return null but in the future we might return something different, either way the return value at this point is critical and needs to be explicitly considered and processed".

Yeah, it was a wild guess. I have a habit of making things more verbose for future maintainers.

To a non programmer or an absolute beginner? Sure, but then I would ask; why in the hell are you writing your code in a style catered to people who don't know what they are doing? That line simply shows that the writer doesn't understand Boolean expressions.

When you find your language forces you to do stupid things, the correct response is not "get in the habit of doing stupid things". It's "find a better language".

I did something of this kind recently and it was to enforce more of an api in my object, like internally I call some low api method that either gives me the object I'm looking for or false / null when doesn't find it, but in my interface I don't want to leak that object, just true or false. So

function isAvailable(){ objInDb = findByName('Joan Carlos'); // the object or false

   return objInDb ? true : false;

}

But all this could be because I'm a noob in a language I don't really know... Php that magical land where nothing is what it looks like and is always ready to stab you in the back, can't say I'm a fan of it... Or dynamic languages, or anything magical... Ok, I'm going to places I don't want to remember, sorry...

I this case, returning objInDb would be semantically different. So, if you always want to return a Boolean, you did the right thing.

Reply on news.ycombinator.com