6

Lately I've been noticing the style of some programmers who write "if" statements backwards. That is, in the test they put the constant value first and then the variable that they are testing second. So for example they write:

bar = foo();
if (MY_CONSTANT == bar) {
    /*  then do something */
}

To me, this makes code somewhat difficult to read. Since we are really talking about testing the value of the variable "bar" and not all variables that are equal to "MY_CONSTANT", I always put the variable first. Its sort of a unspoken grammar.

Anyhow, I see that some programmers ALWAYS do this in the opposite order. Further, I've only noticed this in the past few years. I've been programming in C for over 25 years and I've not seen this until, say, about the last 4 years or so. So my question is:

Is there a reason people are doing this and if so what is it? Is this a common standard in some languages, or projects, or is it taught in some universities? or is that just a few people trying to be different?

vlad_tepesch
  • 6,681
  • 1
  • 38
  • 80
msundius
  • 79
  • 3
  • @vlad_tepesch explains why this style arose; but using it or not is primarily a question of personal opinion and style. – MaxVT Apr 19 '16 at 15:44
  • 6
    Yoda-conditions not using you should. Ancient they are and modern compiler warn will for normal order already. – too honest for this site Apr 19 '16 at 15:55
  • 1
    I don't think that it is all that recent. The university connection might explain why it perpetuates. Professors get tired of dealing with the same bug again and again, and the students making this bug are not the sorts likely to heed compiler warnings. Teaching the students to write it this way could save professors a little bit of time debugging student's code. – John Coleman Apr 19 '16 at 15:56
  • 2
    @JohnColeman: Such code is more and more refused in a professional environment like companies, because compilers will warn about them since >10 years. Teaching students to use them is the wrong approach. Much simpler and more to common practice is to refuse code which generates diagnostics with common warnings enabled. It is more likely the prof once learned it that way and just keeps the habbit. Sadly, most professors don't like learning new tricks if they are not really necessary for their field of interest. – too honest for this site Apr 19 '16 at 16:06
  • I've never seen Yodas refused. I actually prefer them to 'normal' construction that occasionally pushes the actual condition off the rhs of my edit/debugger window because it's a check on the result of some system call with 13 parameters. – Martin James Apr 19 '16 at 16:19

2 Answers2

19

This is called "Yoda-Style" (or "Yoda conditions" or "Yoda notation") and should prevent you from accidentally writing

if (bar = MY_CONSTANT) {
    /*  then do something */
}

since

if (MY_CONSTANT = bar) {
    /*  then do something */
}

would trigger a compiler error.

The name is derived from the uncommon twisted sentence construction the Star Wars character Yoda is also using.

In my opinion using "Yoda-Style" makes understanding of code harder because it is against the normal sentence construction rules. Also code quality checker (or as mentioned in the comments maybe even the compiler itself) should complain about such assignments anyway, so that (imho) there is no good reason to obfuscate your code.

vlad_tepesch
  • 6,681
  • 1
  • 38
  • 80
8

This is something of a best practice which someone thought best 15 years ago or so. Alleged benefit was that it would prevent someone from doing accidental assignments instead of comparison.

It was dubious back than, it is 100% moot nowadays since any compiler worth using will warn about assignment in branch operator, but hordes of lemmings still copy best practice without even thinking what it means or what it is for.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • I routinely, intentionally, perform assignments in conditionals, particularly for `bool`s,, ie `if ((myBool=SomeBoolFunc()) == true){ // do stuff }else{ // do other stuff } // now I can return/use myBool without explicit assignment`. It saves me 2 lines for assigning the `bool` whether true or false (`if true, myBool = true, else myBool = false;`). I'm getting the consensus from these answers/comments that's considered bad practice? – yano Apr 19 '16 at 16:19
  • @yano, compiler will sugges parenthis around this assignment. Not a big deal. – SergeyA Apr 19 '16 at 16:23
  • ok yeah, that was the other thing. Pretty sure I've got warnings turned on and I don't think I've ever seen one warning me about this, but I always make sure to use parenthesis to do the assignment first and then the comparison. Thanks – yano Apr 19 '16 at 16:25
  • 1
    @yano i would consider it to be bad practice, since it hides side effects in an conditional that also may be lead to bugs if the condition is enhanced without reminding that short circuit evaluation may break your assignment. – vlad_tepesch Apr 25 '16 at 16:37
  • @yano As a second remark: comparing bool against bool constants is awkward. 1st it is illogical since the outcome is also a bool that then should be tested against a constant. 2nd: a value of 2 would also considered to be true, but what if `true` is internally considered to be 1 - so you are testing `1==2` (please note that language is C that in its basic form does not has a `bool` type - so someone must have written a define for this that relies on a integer data type) – vlad_tepesch Apr 25 '16 at 16:39