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

31–40 of 116 posts

Re: Yoda conditions

#31

Post by wruza »

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 in my experience.

Re: Yoda conditions

#32

Post by larntz »

reallydontask wrote: post #20

Interestingly enough they are needed when comparing to $null in Powershell https://rencore.com/blog/powershell-null-comparison/

I was going to post this too. I ran into this a year or so ago and now always put $null on the left of a comparison.

Re: Yoda conditions

#33

Post by marcinzm »

logicallee wrote: post #27

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 "statem…

The greatest difficulty with code is not in writing it but in reading it.

Re: Yoda conditions

#34

Post by pmontra »

logicallee wrote: post #27

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 "statem…

Ruby has that.

  x += 1 if !condition
Better as

  x += 1 unless condition
I use them not as an afterthought but by design. This is the Ruby Style Guide about it https://rubystyle.guide/#if-as-a-modifier

Re: Yoda conditions

#36

Post by saw-lau »

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.

I'm so glad somebody else thinks this! I've always hated that style of notation.

Re: Yoda conditions

#37

Post by admax88q »

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…

Yeah but that's also just a ridiculously long line which will be hard to read regardless ;)

Re: Yoda conditions

#38

Post by roland35 »

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.

This is true, but sadly warnings can be ignored! At my last job we enforced -Wall so we had no warnings on pull requests to prevent this though.

Re: Yoda conditions

#39

Post by peterwwillis »

crdrost wrote: post #17
frou_dh wrote: post #9

Treating the symptom: Pollute the codebase with warped code. Treating the cause: Use static analysis.

Treating the cause's cause: use a programming language which makes a distinction between actions and values, so that an action-which-produces-a-boolean is not valid where a boolean is expected. Treating the cause's cause's cause: design your own programming language to be a strongly typed functional or logic programming language that is a descendant of the ideas in XSLT, where the attitude was “the most common thing…

> Probably treating the cause's cause's cause's cause is something like “just use Excel for everything, why are you using these other languages?”

It's be harder to get things done, but we'd be more certain about them

Re: Yoda conditions

#40

Post by dragonwriter »

marcinzm wrote: post #33
logicallee wrote: post #27

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 "statem…

The greatest difficulty with code is not in writing it but in reading it.

if/unless is pretty common in natural language for good reason. I find it far more readable than prefix, block-form if for the simple case of one-line results with no alternative branch.,
Post reply on HN