solution: don't have assignment operator.
Yoda conditions
11–20 of 116 posts
Re: Yoda conditions
#12solution: don't have assignment operator.
Or use ML-style reference cells, so that assignment cannot work on two things of the same type.
Re: Yoda conditions
#13solution: 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."
Re: Yoda conditions
#14solution: 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
T&R are the originators of Unix and C. Kernighan seems to often unwittingly be given Thompson's achievements!
Re: Yoda conditions
#15Treating the symptom: Pollute the codebase with warped code. Treating the cause: Use static analysis.
Alternatively there are languages, where this problem can't arise at all.
In Clojure for example: (= ...) just tests for (actual) equality, while (def ...) assigns a symbol to a value, or (swap! atom f) changes the value of an atom (reference type).
Re: Yoda conditions
#16Am 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 accidentally.
I've actually noticed one thing about Common Core is that they do try much harder than when I was a kid to not accidentally create that impression; my kid's homework is full of "4 + 3 = ___" followed immediately by "____ = 8 + 2". 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". (I mean, there's a sense where such students aren't even wrong; it is the rational conclusion from the evidence presented.)
Re: Yoda conditions
#17Treating 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 you do in programming is to map one data structure into another, so let’s build the whole language around making those mappings easy first.” There can now be no confusion.
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?”
Re: Yoda conditions
#18Am I sure pretty any that linter warning a throw can of instead breaking flow the both of reading writing and.
Haha it took me a second to realize what you did there
Re: Yoda conditions
#19All 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.
Re: Yoda conditions
#20Interestingly enough they are needed when comparing to $null in Powershell