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

21–30 of 116 posts

Re: Yoda conditions

#21

Post by AllegedAlec »

jerf wrote: post #16
arpa wrote: post #4

Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.

Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accide…

> 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.

Re: Yoda conditions

#23

Post by na85 »

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.

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

Re: Yoda conditions

#24

Post by ninkendo »

jerf wrote: post #16
arpa wrote: post #4

Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.

Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accide…

> If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator

Code is for humans, not computers. The order I choose when writing an expression is driven by what I want to convey to the next person reading my code.

`if (button.state == .enabled)` suggests to the reader that the button’s state is the thing we’re interested in in this particular piece of code. Reversing the operands is confusing not because I don’t understand the communicative property, it’s confusing because it puts the emphasis on the wrong thing: I’m not checking if the enabled state matches an expectation, I’m checking if the button’s state matches an expectation. And I want the reader to understand that.

Re: Yoda conditions

#25

Post by shultays »

na85 wrote: post #23
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.

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)

Re: Yoda conditions

#27

Post by logicallee »

only tangentially related, but one of the things I miss so much about Perl is that, as in English, you can add an "if" or "unless" clause as an afterthought.

$x++ if (!condition);

like if you start to increment $x++ and then you realize wait a second I only mean if....

"unless" likewise functions as an "if not".

This is such a "natural" way to write.

Let's compare what happens if you have the thought to add a "statement modifier" in any other programmer language.

you're written your statement, and now you have to go back to the beginning of your line, write your condition, open a brace, go back to the end of the line, and close your brace. Or maybe begin an entire code block, since you can't have it on one line anymore.

it is so much less natural. why can't other programming languages have that?

Re: Yoda conditions

#28

Post by bregma »

AllegedAlec wrote: post #21
jerf wrote: post #16

Earlier quoted context omitted.

Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accide…

> 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.

Re: Yoda conditions

#29

Post by jameshart »

jerf wrote: post #16
arpa wrote: post #4

Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.

Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accide…

There are two perfectly valid ways of reading

   x == y
aloud as an English statement:

> X equals Y

> X and Y are equal

The first sentence uses active voice - the second passive. Active voice ascribes agency to X; It makes a subject/object distinction between X and Y. Passive voice makes them both objects.

When reading code, it makes more sense to ascribe agency to variables than to constants, which is why people are more comfortable reading x == 0 than 0 == x. Zero can’t change, so it can’t do anything to make itself equal something. X can change, so it is capable of equaling things.

If you’re equally comfortable with either formulation, maybe you just prefer the passive reading of the sentence.

But I do wonder if you’d be equally happy if I went through your codebase and replaced every for loop condition from i i...

Post reply on HN