Earlier quoted context omitted.
Only if status is initialised to something other than SUCCESS.
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.
Yoda conditions
81–90 of 116 posts
Re: Yoda conditions
#82Am 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…
[deleted]
Re: Yoda conditions
#83Earlier 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…
> 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…
[deleted]
Re: Yoda conditions
#84only 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…
Forth love if honk then
Be careful what you wish for...
Re: Yoda conditions
#85I 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...)
Just wait until people realize proportional fonts are actually easier to read than mono-spaced fonts.
Re: Yoda conditions
#86Earlier 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…
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 mo…
[deleted]
Re: Yoda conditions
#87I once worked for a place that explicitly told me not to do this. They also told me to test booleans with
if( booleanVariable == true ) ...
Re: Yoda conditions
#88All 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.
> Leave a comment there explaining the assignment.
Please don't. This is a perfectly understandable idiom in C. Don't explain the language in your comments; that's the job of a text book, which should be read by anyone before they read your code.
Re: Yoda conditions
#89All 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.
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?
Re: Yoda conditions
#90I'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.
> so it makes sense to put the important information
Both sides of the equality check are equally important.