21–30 of 82 posts
Earlier quoted context omitted.
I'm guessing you don't realize that the plus operator has less precedence than the == operator. That if is equivalent to if (startDate + true) EDIT: I was wrong. I haven't slept.
Does it mean if(1 + 1 == 2) is equivalent to if(1 + true)?
Love this one: return foo == null ? null : foo;
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.
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.
Earlier quoted context omitted.
I'm guessing you don't realize that the plus operator has less precedence than the == operator. That if is equivalent to if (startDate + true) EDIT: I was wrong. I haven't slept.
Sadly you are wrong. See an operator precedence list: http://bmanolov.free.fr/javaoperators.php
Earlier quoted context omitted.
This reminds me of this one, which is quite common: return foo == null ? true : false;
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.
Love this one: return foo == null ? null : foo;
> if (Session["startDate"] + "" == "") This feels horribly familiar. I'm not sure to recognize the specific language used, but there must be cases where one would like to target empty of filled with non processable characters strings only, and let null and falsy values pass through. This kind of use would typically need a line of comment, but hey...
if "x$VARIABLE" == "x"
Earlier quoted context omitted.
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.
The result of "foo == null" (or better "foo === null") is boolean, I don't know what is the "equivalence" problem here.
Love this one: return foo == null ? null : foo;
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.
Or maybe it's just stupid.
Sometimes you just can't tell the difference.
> if (Session["startDate"] + "" == "") This feels horribly familiar. I'm not sure to recognize the specific language used, but there must be cases where one would like to target empty of filled with non processable characters strings only, and let null and falsy values pass through. This kind of use would typically need a line of comment, but hey...
I shell languages I do this a lot. if "x$VARIABLE" == "x" because it handles the cases where $VARIABLE is undefined or multiple words without vomiting all over the place.
if [[ "$VARIABLE" == "" ]]
if [ -z "$VARIABLE" ]
Earlier quoted context omitted.
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;
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.