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

11–20 of 83 posts

Re: Yoda Conditions

#11

Post by akerro »

mikeash wrote: post #8
michaelmior wrote: post #5

Earlier quoted context omitted.

While I don't disagree, curious to hear your reasoning for not doing this.

It's unnatural, confusing to read, and won't save you anyway in cases where you're comparing two variables. It's OK if your tools absolutely can't diagnose accidental if(a = b), but it should be the last resort.

In some languages it's better to use it, eg. in Java you can go with:

   mString != null && mString.equals("test")
or

   "test".equals(mString)
They do the same, but the second one adds hidden `defensive programming` to prevent NPE in `equals`. Saves time AND code.

Intended usage of if(a=b) should be written as if((a=b)). Don't know what tool you use at work or at home, but most static code analysers will point you that. Try SonarQube at least.

Re: Yoda Conditions

#12

Post by paol »

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.

Yes, "foo".equals(bar) is useful in Java if bar can be null, but that's a different thing.

Re: Yoda Conditions

#13

Post by selfsimilar »

In PHP I like using Yoda Conditions because there's a common idiom of testing assignment in the conditional:

    if ($value = getSomeValue()) {
      // Safely use value
    }
Yoda Conditions defend nicely against accidents when '=' and '==' can be used legally this way and honestly you get used to reading them pretty quick.

Re: Yoda Conditions

#14

Post by paol »

michaelmior wrote: post #5
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.

While I don't disagree, curious to hear your reasoning for not doing this.

This trick can only save people who remember to use it. Warnings emitted by tooling save everyone.

Also it's slightly awkward to read, as mentioned by others already.

Re: Yoda Conditions

#15

Post by scj »

mikeash wrote: post #8
michaelmior wrote: post #5

Earlier quoted context omitted.

While I don't disagree, curious to hear your reasoning for not doing this.

It's unnatural, confusing to read, and won't save you anyway in cases where you're comparing two variables. It's OK if your tools absolutely can't diagnose accidental if(a = b), but it should be the last resort.

> It's unnatural, confusing to read ...

I feel as if that can rephrased "Don't do it because it is not done." A left-hand side constant is a convention that can have practical benefits in limited cases. Which at least should merit consideration.

Re: Yoda Conditions

#16

Post by hashkb »

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.

Re: Yoda Conditions

#17

Post by brianwawok »

paol wrote: post #12
brianwawok wrote: post #6

Earlier quoted context omitted.

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

Yes, "foo".equals(bar) is useful in Java if bar can be null, but that's a different thing.

Not really different. In fact is is mentioned on the Wikipedia page.

Re: Yoda Conditions

#18

Post by mikeash »

scj wrote: post #15
mikeash wrote: post #8

Earlier quoted context omitted.

It's unnatural, confusing to read, and won't save you anyway in cases where you're comparing two variables. It's OK if your tools absolutely can't diagnose accidental if(a = b), but it should be the last resort.

> It's unnatural, confusing to read ... I feel as if that can rephrased "Don't do it because it is not done." A left-hand side constant is a convention that can have practical benefits in limited cases. Which at least should merit consideration.

"Don't do it because it is not done" is a good reason unless you're working solo and are sure your code will never be seen by others. And even then, it's a good idea to stick to what's done so you don't accumulate bad habits for projects that do have others looking at the code.

Re: Yoda Conditions

#19

Post by MikkoFinell »

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.

Also clang warns "using the result of an assignment as a condition without parentheses".

Re: Yoda Conditions

#20

Post by dom96 »

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.

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