Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yoda Conditions

en.wikipedia.org

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Yoda Conditions

#31

Post by efaref »

mikeash wrote: post #10
koolba wrote: post #4

A similar but arguably more useful version of this is when you have two variables, one of which may be null. Traditionally you issue an if-condition test using the variable user input as the left operand but switching it handles the null case automatically. Ex: Foo SOME_CONSTANT = ; Foo userSuppliedInput = ; // This can raise an null pointer exception if (userSuppliedInput.isEquals(SOME_CONSTANT) { // ... } // This c…

Objective-C is really fun here. Messages to nil are no-ops which return zero, which for booleans results in false. Thus, the conditional works just fine either way: if([userSuppliedInput isEqual: SOME_CONSTANT]) { ... If userSuppliedInput is nil, the isEqual: returns false, and it works. It gets really fun when both might be nil: if([a isEqual: b]) { ... If a and b are both nil, then they're conceptually equal, but i…

Not sure I like the sound of that. It sounds like the floating point wat of "NaN != NaN".

Re: Yoda Conditions

#32

Post by kibwen »

junke wrote: post #25
dom96 wrote: post #20

Earlier quoted context omitted.

There is nothing wrong with using equals for assignment, the language designers just have to disallow assignments in if conditions.

One more corner case, instead of designing orthogonal features.

It's not a corner case if you do it right.

For example, in C the assignment operator evaluates to the value of the right-hand side expression (so `int x = (y = 2);` initializes `x` to 2). But in Rust, the assignment operator always evaluates to `()` (a.k.a. "unit", the empty tuple), and trust me, this is how you want the language to work in the presence of pervasive move semantics and single ownership. Furthermore, nothing in Rust is "truthy": if-expressions accept a boolean and nothing else (this is also, IMO, exactly what you want in every language, but I'm sure others will disagree :P ). So `if x = 2 {` is a compiler error in Rust because `()` can't be coerced to a boolean (to say nothing of the fact that this reassignment would probably be a compiler error anyway because most variables in Rust are immutable). This doesn't require any acrobatics, it's just the natural fallout of how the rest of the language works.

Re: Yoda Conditions

#34

Post by junke »

kibwen wrote: post #32
junke wrote: post #25

Earlier quoted context omitted.

One more corner case, instead of designing orthogonal features.

It's not a corner case if you do it right. For example, in C the assignment operator evaluates to the value of the right-hand side expression (so `int x = (y = 2);` initializes `x` to 2). But in Rust, the assignment operator always evaluates to `()` (a.k.a. "unit", the empty tuple), and trust me, this is how you want the language to work in the presence of pervasive move semantics and single ownership. Furthermore, n…

Thanks, that's indeed a sensible way to do that.

Re: Yoda Conditions

#35

Post by marcosdumay »

hashkb wrote: post #16
paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

The real lesson is for language designers, who for some reason love using equals for assignment. Lisp got it right a hundred years ago and nobody learned.

Well, languages can either use another assignment operator or have type system that wont check that kind of statement. Both ways fix it.

In fact, it's not easy to have this kind of bug on your language. C just has it because people wanted to write stuff like `int a = b = 0`.

Re: Yoda Conditions

#36

Post by kentt »

nayuki wrote: post #22

I would say that the phrase "Yoda conditions" more appropriately describes Ruby's alternative form of if-statements: if x > 0: y += x versus y += x if x > 0

One of the worst parts of Ruby. I can see the argument that it could be better to have

  save if valid
rather than

  if valid
    save
  end
but what I see 9 times out of 10 is

  things.do each |thing|
    foo
    bar
    baz
  end if valid
or

really.long.thing.that.i.try.to.parse.in.my.head if acutally_almost_never_happens

which is harder to read since I read top to bottom / left to right, but the flow is bottom to top and right to left

Re: Yoda Conditions

#37

Post by [deleted] »

dom96 wrote: post #20
hashkb wrote: post #16

Earlier quoted context omitted.

The real lesson is for language designers, who for some reason love using equals for assignment. Lisp got it right a hundred years ago and nobody learned.

There is nothing wrong with using equals for assignment, the language designers just have to disallow assignments in if conditions.

[deleted]

Re: Yoda Conditions

#38

Post by busterarm »

paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

Counterargument:

Do do this if the coding standards for the language/framework you're working in require it. Like WordPress.

Re: Yoda Conditions

#39

Post by megawatthours »

brianwawok wrote: post #6
paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

Eh, I think it is good in Java in cases where Null input is possible.

I never got the Java argument. I would much rather fail early and noisily with an NPE than return false and let my program happily chug along when it wasn't expecting a null. If the value is intended to be nullable, I would use an optional.

Re: Yoda Conditions

#40

Post by Gaelan »

kentt wrote: post #36
nayuki wrote: post #22

I would say that the phrase "Yoda conditions" more appropriately describes Ruby's alternative form of if-statements: if x > 0: y += x versus y += x if x > 0

One of the worst parts of Ruby. I can see the argument that it could be better to have save if valid rather than if valid save end but what I see 9 times out of 10 is things.do each |thing| foo bar baz end if valid or really.long.thing.that.i.try.to.parse.in.my.head if acutally_almost_never_happens which is harder to read since I read top to bottom / left to right, but the flow is bottom to top and right to left

You can write gibberish in any language. You shouldn't kill useful features because they are sometimes misused.
Post reply on HN