if(false==condition). Why?

Question

I have received code from someone working earlier on it, and it contains a lot of lines like

while(false==find && false == err && k<kmax)
if(true==refract(ep1,ep2,n1,RI_blood, RI_collagen))

and my favorite line is

if(false == (ret_s<0))

The other code is done really well, documented just fine, but these lines with these odd conditions are throwing me off, and I wonder why they are done that way.

Especially that false==(ret_s<0) is completely confusing, and you kind of need to read that line like three times to understand what they want there.

Is this a common programming style, don't I understand the reasoning for that, or is that just bad style?

Edit: I don't feel this is similar to if(object==NULL) vs if(NULL==object), since this isn't about accidental assigning but about obfuscated if clauses...

Compilers warn on using `=` instead of `==`, so I see no reason to obfuscate it. — chris, Jun 03 '13 at 20:22
As others have said, it avoids accidental assignments. That said, unless you're developing programs in a text editor, it's wretchedly bad style; most modern IDE's will warn you. — Robert Harvey, Jun 03 '13 at 20:23
@RobertHarvey, And if the Intellisense doesn't exist, the compiler will. — chris, Jun 03 '13 at 20:24
@RobertHarvey but there is no need to compare against `true` or `false`. — juanchopanza, Jun 03 '13 at 20:24
@500-InternalServerError: I know some of those that prefer to not use parentheses anywhere and call their code self-documenting. Yay! Also I'd rather see the comparison at the beginning of the line than have it extend beyond the horizontally visible length of the line ... — 0xC0000022L, Jun 03 '13 at 20:26
There is basically no reason, other to alert the user that the author of the code didn't know what they were doing. It is a pretty good red flag. — juanchopanza, Jun 03 '13 at 20:27
possible duplicate of [What is the difference between these (bCondition == NULL) and (NULL==bCondition)?](http://stackoverflow.com/questions/5854317/what-is-the-difference-between-these-bcondition-null-and-null-bcondition) or http://stackoverflow.com/questions/6830176/what-is-the-meaning-of-null-value-in-c and so many many more — David Heffernan, Jun 03 '13 at 20:53
Keep in mind that the last example may be the result of being edited several times. When bug fixing it's often safer to minimize the changes, even if some modest nonsense is left behind. — Hot Licks, Jun 03 '13 at 21:30
This is called "Yoda Code" http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html — Erty Seidohl, Jun 03 '13 at 22:22
Egad. My opinion is that if you are testing a boolean, don't put the `false ==` or `true ==` into it. Either test the right-hand-side directly, or use the `!` operator on it. (But only bool. I prefer if one is testing an `int` against `0`, to explicitly put in the test for `0`: `expr == 0`.) — Andre Kostur, Jun 04 '13 at 01:00
It seems to me that if you *always* code your IF-conditions like this, you'd very quickly start reading **if (false == (X))** as **UNLESS(X)**. And let's face it - in OP's specific example, it would actually be more "natural" to think of **X** as the thing you *don't* want to be true if you're going to execute the IF-code. — FumbleFingers, Jun 04 '13 at 01:54
I'm a little unnerved at how many people jumped on putting the constant first, and completely missed the unnecessary and confusing boolean comparisons... — Izkata, Jun 04 '13 at 03:33
Coincidentally putting the constant first also follows the normal assert pattern of 'expected, actual'; also, I would encourage refactoring expressions that are composed of multiple conditions into their own query-style function. — JustinC, Jun 04 '13 at 04:30
@JustinC: How is a Yoda-style assert "normal"? I'd always write `assert(actual == expected)`, just as I'd write `if (actual == expected)`, in line with the common conventions of the English language. Your idea of "normality" seems to be an offshoot of the very reasoning that gave rise to the bizarre code presented here. — Mike Seymour, Jun 04 '13 at 23:36
@MikeSeymour the testing frameworks I have used lately have followed the convention of assert(expected, actual,...); and the message format that is emitted from a failed assertion seems more natural. footest expected but got — JustinC, Jun 05 '13 at 00:35
@DavidHeffernan: I don't feel this is a duplicate of foo==NULL or NULL==foo, since this is a comparison to a boolean. I know why you do it in one order or the other for objects, but I dont feel this is the same. — SinisterMJ, Jun 05 '13 at 12:48

Mike Seymour · Accepted Answer · 2013-06-03T20:35:00.447

Is this a common programming style?

No.

don't I understand the reasoning for that?

Some people like to explicitly compare booleans with true or false, even though the result is exactly the same boolean value. The logic is presumably that, by making the code harder to read and more surprising, people will think harder about it and make fewer assumptions about its behaviour. Or perhaps just that code should be hard to maintain, since it was hard to write.

Others like to write comparisons with constants backwards, which prevents mistakes like if (x = 5) when you meant if (x == 5). Any modern compiler will warn you about this mistake, so again its only real purpose is to make the code harder to read.

Combining these two behaviours gives the bizarre code you posted.

Or is that just bad style?

It's a style. I'm no judge of style, but if you like to keep maintainence programmers on their toes, it certainly does that. Personally, I like my code to be readable, but that's just me.

my favorite line is

I once encountered return a && !b implemented in about ten lines of code. The first line was switch(a).

+1 for `Personally, I like my code to be readable, but that's just me.` — Mark B, Jun 03 '13 at 20:27
+1, although I see it more as a call for help. "I am not sure what I am doing here, please treat my code with the utmost attention". — juanchopanza, Jun 03 '13 at 20:29

score 42 · Answer 2 · edited Mar 03 '18 at 02:49

42

Yoda Conditions

enter image description here
Using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it's like saying "if blue is the sky" or "if tall is the man".

edited Mar 03 '18 at 02:49

Abdulrahman Bres

2,603
1
20
39

answered Jun 03 '13 at 23:14

Chad

2,938
3
27
38

http://www.youtube.com/watch?v=hEcjgJSqSRU – Chad Jun 04 '13 at 03:04
1

I like Yoda conditions, because they express the intention of the conditions. If one would forget a `=` you would get the expression `(5 = count)` which would lead to an error. But if you use the notation `(variable == constant)` you would get an assignment `count = 5`. And this kind of semantic errors are harder to debug. – akristmann Jul 02 '13 at 09:37
For more on this, look here: https://blog.codinghorror.com/new-programming-jargon/ – davidmpaz Aug 13 '19 at 10:54

score 16 · Answer 3 · answered Jun 03 '13 at 20:20

16

Its a safe guard against assignment in C++.

In C++ it is perfectly legal to do this

if (foo = true) ....

In this case the single = is an assignment and would replace the value of foo.

This is not legal and will generate a compiler error

if (true = foo) ....

answered Jun 03 '13 at 20:20

Daniel A. White

187,200
47
362
445

5

So is `if (!condition)` – Mike Seymour Jun 03 '13 at 20:21
2

exactly.. ! is the same as false == except it's easier to read.. – Dory Zidon Jun 03 '13 at 20:22
1

What is wrong with `if (foo)`? – juanchopanza Jun 03 '13 at 20:22
1

You can't assign a value to `true` or `false`, so an erroneous substitution of `=` for `==` will produce a syntax error if `true` or `false` comes first. It gets to be a bit of a habit/obsession with some programmers (or they're slavishly observing some "coding standard"), so they use the form even when it makes no sense. – Hot Licks Jun 03 '13 at 20:23
(!condition) is even safer + not ugly. – Sceptical Jule Jun 03 '13 at 20:24
@ScepticalJule - You see a lot of stuff much uglier than that. – Hot Licks Jun 03 '13 at 20:26
2

And of course, you can't assign anything to `(ret_s<0)`. – Mike Seymour Jun 03 '13 at 20:40

score 6 · Answer 4 · edited Jun 03 '13 at 20:22

6

Constants and literals are often put on the left because it prevents accidental assignments. Consider typing:

if(foo == bar)

as:

if(foo = bar)

The second might appear to work... but silently clobber foo. If foo is a constant, this error is not longer possible.

edited Jun 03 '13 at 20:22

0xC0000022L

20,597
9
86
152

answered Jun 03 '13 at 20:22

Cory Nelson

29,236
5
72
110

score 4 · Answer 5 · answered Jun 03 '13 at 20:22

It's a self-protection technique that prevents you from accidentally typing an assignment operator (=) instead of equality operator (==), which can introduce strange bugs. Putting the constant value on the left hand side will introduce a compiler error, while putting a variable on the LHS will just silently compile.

score 4 · Answer 6 · answered Jun 03 '13 at 20:24

Perhaps the original programmer thought that explicit comparison to true or false was clearler than if(condition) or if(!condition) and coded things in that way. I haven't seen this particular style before however.

It's quite subjective but I find while(!find && !err && k<kmax) easier to read.

score 1 · Answer 7 · answered Jun 03 '13 at 23:05

The code could have been written for a shop where there is a site standard that every conditional statement must include a comparison operator, in order to avoid accidentally leaving out part of the comparison. (Maybe that's a stretch, but you did say that the rest of the code was very good.) That, coupled with a standard or habit of putting the constant on the left to avoid accidentally using = instead of == would give pretty much the code you showed. It doesn't explain the use of 'false' instead of the more natural 'true', though. Maybe it's a (misguided on multiple levels) attempt to gain microefficiency by comparing to zero instead of 1 at the machine level.

VhsPiceros · Answer 8 · 2013-06-03T20:30:53.867

-1

for my is only bad style,

if(false == (ret_s<0))

is equals to in C#

if(!(ret_s<0))

edited Jun 03 '13 at 20:30

answered Jun 03 '13 at 20:23

VhsPiceros

410
1
8
17

7

quite the opposite. – Luchian Grigore Jun 03 '13 at 20:24
yes, sorry.I am thinking in c#, sorry again – VhsPiceros Jun 03 '13 at 20:26
2

It's still the opposite in C#. – chris Jun 03 '13 at 20:29
yep, should be if(!(ret_s<0)) – VhsPiceros Jun 03 '13 at 20:30
In this particular case, I think that `if(false != (ret_s<0))` is the most readable way to write this code... – Matthieu Rouget Jun 03 '13 at 20:30
7

Amusingly, if `ret_s` is a `float` or `double`, `false == (ret_s<0)` is not equivalent to `ret_s >= 0`. If it's an IEEE NaN, the first is `true` and the second is `false`. – Eric Jablow Jun 03 '13 at 20:34

if(false==condition). Why?

8 Answers8

Yoda Conditions

Linked

Related