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

71–80 of 116 posts

Re: Yoda conditions

#71

Post by jerf »

bregma wrote: post #28
AllegedAlec wrote: post #21

Earlier quoted context omitted.

> Still kind of glossing over "=" as a "simplify" operator, but it's still an improvement over when I was a kid when it was really easy to pick up the idea that the "=" operator was actually a function meaning "take the expression on the left and simplify it". What? No. De '=' sign is very simple: what's written to the left of it is equal to what's written on its right.

The takeaway that many students have is that the equals sign if equivalent to the -> sign, which definitely implies simplification. I know I was set straight as a university freshman in the 1980s, and I have read many things since about that same confusion. Outside of math it probably doesn't matter. Inside of math it matters a lot. Programming is math.

I just want to confirm this is what I meant. While I wasn't as badly affected as some of my peers, I still remember when I truly realized what equality meant. That occurred in college, and embarrassingly late in college at that (though it was in undergrad at least). I suspect I got some extra cognitive interference from my programming language experience, so non-programmers would hopefully have an easier time of it.

And I was solving systems of equations with substitution and doing all the usual things to equations one does in math classes, and to all external appearances I would have looked like I understood equality prior to that. But I didn't. Not fully. In hindsight, the best evidence of this was in physics class, where I was perfectly adequate at taking the provided equations and using them, and I understood their derivation, but I still wasn't all that great at combining them fluidly; F = ma, yes, but it still didn't quite fully register that that meant anywhere I saw an F, in any other equation in which it appeared, I could drop in an ma. It's not that F is "convertable" to ma, or that ma simplifies to F, or that the name of ma is F... it's that they ARE each other, there is no conceivable way you can separate them, there is no conceivably witnessable in any way, mathematically or practically, effect from substituting one for the other, there is only one entity that can be named in various ways. I did not fluidly combine them the way I should. If I had the class to do over again, I would do way better this time, even we could somehow erase my first pass entirely from my mind.

Re: Yoda conditions

#72

Post by T-hawk »

wruza wrote: post #31
jedisct1 wrote: post #19

All linters and C compilers emit a warning when an assignment is made in a condition. There are zero reasons to use that ugly and unnatural Yoda notation in 2019.

if (systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT) != 0) if (0 != systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) One may find it easier to read/navigate flow control in C code that returns status codes, when these codes are stated beforehand. When there are series of long lines and a mix of 0==success and 0==false, it is easy to get lost, at least…

I'd break this up by lines, every time.

  int result = systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT))
  if (result != 0)
Separation of concerns. Each line does one thing. Making a system call and branching on its result are two separate tasks.

Re: Yoda conditions

#73

Post by carapace »

kemiller2002 wrote: post #65

I know I'm in the minority, but I honestly never really understood why people get so up in arms about this. People keep saying it's so difficult to read, and I just don't understand why. I know that linters and such can catch this most of the time, but a lot of places I've seen don't use them. (I don't know why, that's a whole other discussion.) It just seems to me that it's something that keeps you from wasting time…

You must be young, friend. The holy wars that used to rage over just where to put curly brackets...

(And then Python came along and was like, "U wot mate?", and there were had little wars over "syntactically-significant indentation" and tabs vs. spaces, and how many spaces... And on, and on...)

Re: Yoda conditions

#74

Post by yegle »

memorysafety wrote: post #68

So I'm writing a unit test. I bet everyone here can correctly guess the language. assert ('Content-Type', 'text/plain') in dupefail.headers assert b"registration denied" in dupefail.body assert "403 Forbidden" == dupefail.status I also happen to pay attention to the linter fart^Woutput: C: 61,11: Comparison should be dupefail.status == '403 Forbidden' (misplaced-comparison-constant) I totally admit my thorough hate o…

That's why normally you do self.assertEqual() instead of assert.

To properly support assert with good error reporting, pytest has to rewrite the byte code. See http://doc.pytest.org/en/latest/assert.html#assert-details

Re: Yoda conditions

#75

Post by adrianmonk »

shultays wrote: post #25
na85 wrote: post #23

Earlier quoted context omitted.

Do compilers for other languages emit the same warning? Because there are fewer and fewer reasons to use C in 2019 as well.

Not all languages allows chained assignment (a=b=c) like c++ does, which is why we have this problem (and probably does not automatically cast them to bool either)

Chained assignment isn't the reason. The similarity of the "=" and "==" operators is.

Specifically, it's both (1) easy to make a typo where you meant "==" but typed "=" and (2) not easy to visually distinguish the two.

Re: Yoda conditions

#76

Post by np_tedious »

yegle wrote: post #74
memorysafety wrote: post #68

So I'm writing a unit test. I bet everyone here can correctly guess the language. assert ('Content-Type', 'text/plain') in dupefail.headers assert b"registration denied" in dupefail.body assert "403 Forbidden" == dupefail.status I also happen to pay attention to the linter fart^Woutput: C: 61,11: Comparison should be dupefail.status == '403 Forbidden' (misplaced-comparison-constant) I totally admit my thorough hate o…

That's why normally you do self.assertEqual() instead of assert. To properly support assert with good error reporting, pytest has to rewrite the byte code. See http://doc.pytest.org/en/latest/assert.html#assert-details

Even with them, I do find it Yoda-like that you are supposed to make the expected value be the first argument

Re: Yoda conditions

#77

Post by lugg »

kemiller2002 wrote: post #65

I know I'm in the minority, but I honestly never really understood why people get so up in arms about this. People keep saying it's so difficult to read, and I just don't understand why. I know that linters and such can catch this most of the time, but a lot of places I've seen don't use them. (I don't know why, that's a whole other discussion.) It just seems to me that it's something that keeps you from wasting time…

Code is for humans. If your language lets you make silly mistakes maybe it needs to stop doing that. Why can I assign during a branch? It's unnecessary.

Re: Yoda conditions

#78

Post by bbmario »

T-hawk wrote: post #72
wruza wrote: post #31

Earlier quoted context omitted.

if (systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT) != 0) if (0 != systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) One may find it easier to read/navigate flow control in C code that returns status codes, when these codes are stated beforehand. When there are series of long lines and a mix of 0==success and 0==false, it is easy to get lost, at least…

I'd break this up by lines, every time. int result = systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) if (result != 0) Separation of concerns. Each line does one thing. Making a system call and branching on its result are two separate tasks.

By that logic, shouldn't you be creating a var for the expression_argument() return?

Re: Yoda conditions

#79

Post by T-hawk »

bbmario wrote: post #78
T-hawk wrote: post #72

Earlier quoted context omitted.

I'd break this up by lines, every time. int result = systemcall(“some string”, expression_argument(args), SC_MODE_1 | SC_MODE_DEFAULT)) if (result != 0) Separation of concerns. Each line does one thing. Making a system call and branching on its result are two separate tasks.

By that logic, shouldn't you be creating a var for the expression_argument() return?

Indeed I probably would, just didn't want to distract from the central point in that post.

Re: Yoda conditions

#80

Post by Izkata »

Sahhaese wrote: post #52
beatgammit wrote: post #45

Earlier quoted context omitted.

I think this is reasonable readable: while ((status = systemcall(...)) != SUCCESS) { do something with status; } Leave a comment there explaining the assignment. Likewise: if ((status = systemcall(...)) != SUCCESS) goto error; Or something like that. I don't understand the hate, just make sure it's obvious what you're doing.

This would achieve the same but is far more readable: while(status != SUCCESS) { status = syscall(...); // do something with status }

Your transformation has introduced a bug: the loop body will run once after success turns false.
Post reply on HN