Live data from Hacker News

Yoda conditions

en.wikipedia.org

41–50 of 116 posts

Re: Yoda conditions

#41

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.

[deleted]

Re: Yoda conditions

#42

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. But you have to be careful that your code stays readable. I know that's not a concern for Perl. :-)

Although the "unless" case very often trips me. Somehow my brain can't parse that correctly and I've found that surprisingly many work colleagues have the same problem.

Re: Yoda conditions

#44
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…

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

You either grow it to the right, or in a vertical direction. If the latter, conditions also disperse across that axis. What matters more in a specific case is up to the writer to decide who tries to remain both readable and concise. Highlighting important details in a homogeneous text is part of “the art”.

Re: Yoda conditions

#45

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

Re: Yoda conditions

#46
post #13
post #11

solution: don't have assignment operator.

Or even use plain old := for assignment to help avoid confusion with ==. I wonder if K & R wanted to save a character for terseness. I mean, these are the guys who said, if they were writing Unix again, would "spell creat with an e." https://en.wikiquote.org/wiki/Ken_Thompson

[deleted]

Re: Yoda conditions

#47

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.

[deleted]

Re: Yoda conditions

#48

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.

Furthermore, when we have a problem, if our solution is to have human beings simply remember to do it a different way, we then have two problems.

Re: Yoda conditions

#49

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.

Re: Yoda conditions

#50

I've found it's better to write normal conditions that are easier to read and leave it to your linter to catch unintended assignments.

Are they really easier to read though? A lot of the time which variable being tested is obvious, so it makes sense to put the important information - the value - first.
Post reply on HN