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

111–116 of 116 posts

Re: Yoda conditions

#111

Post by dpzmick »

Izkata wrote: post #81
blktiger wrote: post #66

Earlier quoted context omitted.

So use a do-while instead.

And this introduces another bug: it'll run the loop body even if syscall fails the first time it's run.

I've been going with this style for things like reading files (with retries) or any sort of loop that feels awkward.

  while (1) {
    int ret = ...;
    if (ret == ...) break;
    if (ret == some_other_condition) break;
    // additional termination conditions....
    // do exactly one thing
  }

Re: Yoda conditions

#112

Post by memorysafety »

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

Look, I'm trying to humanly argue against the statement "Yoda conditions are unnatural". Nature has no boolean conditions. That statement should instead say "Yoda conditions are unfamiliar (to me)" -- at which point it's way easier to see the statement's applicability limits, and dramatically narrow down its consequences.

On the contrary; there're many common contexts where Yoda comparisons looks more "natural", meaning they avoid breaking the surrounding code flow, and bring the important part (the constant) up-front. I even brought up a real-world example. Having read `assert "403 Forbidden" == ` and remembering the context, can't you already guess the RHS (and just skim over it)? Sure you can. Non-yoda loses here.

Be aware: you don't have to take a "for/against" side in this debate, as our buggy brains try to in every flame war. Both sides have a point. Familiarize yourself, and decide on case-by-case basis.

While we're at it: self.assertEqual() is super-ugly and unnatural, in my judgement. Why am I forced to use _thrice_ as much words to express the simple single-word concept of an assert? Why can't I spare the extra pair of parens, and spell == directly? I see nothing wrong with bytecode rewriting; it's amazing they can do it, and I appreciate the effort.

Re: Yoda conditions

#113

Post by pluma »

joombaga wrote: post #61
pluma wrote: post #26

Earlier quoted context omitted.

Now you're thinking with ~portals~ monads.

HN doesn't support markdown strikethrough, but here's the text in unicode: p̶o̶r̶t̶a̶l̶s̶

That seems like it would cause problems with screenreaders though.

Re: Yoda conditions

#114

Post by adrianmonk »

shultays wrote: post #108
adrianmonk wrote: post #75

Earlier quoted context omitted.

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.

It is part of the reason. In c++ a=b returns a reference to a to allow chain assignments. And also in c++, most stuff casts to bool automatically when you use them as an if condition. When you have both and make the typo, it gives you a relatively silent bug instead of a compile error. Yea sure, the reason is a typo and easily mistakable operators but the actual reason is the code compiles fine Java for example expec…

Yeah, valid point. Those other things are factors.

If C didn't allow assignments to be used as expressions, then it wouldn't be an issue.

Chained assignment isn't the only way to use an assignment within an expression, so I think it's still more accurate not to say chained assignment as the cause, but chained assignment might have been a big part of the motion for making assignments expressions instead of just statements.

Re: Yoda conditions

#115

Post by emilfihlman »

weberc2 wrote: post #49
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.

Which is great if your project treats warnings as errors. Not sure how common this is though since every time I compile a C program it’s just pages and pages of warnings.

Exactly. All code I write must pass -Wall -Werror -Wextra and there's always a debugging phase once you have written the code since there are syntax errors and whatnot, a lot.

Re: Yoda conditions

#116

Post by johnfactorial »

NoodleIncident wrote: post #92
muench wrote: post #89

Earlier quoted context omitted.

I find this quote very powerful. I'm thinking I could re-use it. Is it yours or if it's sourced from somewhere could you share the source?

It seems like an intentional reference to this quote (Jamie Zawinski): "Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."

LOL That quote is exactly what I was cribbing from. :)
Post reply on HN