1. 17
  1. 7

    I was influenced by some book (maybe Deep C Secrets?) to do this and got so used to it that I no longer see it as weird at all. I no longer see it as a necessary thing (if you’re confusing = and == you’ve got bigger problems) but it shook me from the SVO bias that the title of this article displays. Now I just type whatever order naturally comes to mind (and after all this time, it’s as likely to be VOS as VSO, in lisp).

    Neither avoid nor insist on Yoda conditions.

    With > vs <= etc sometimes one or the other is way cleaner, or equality with partial application in a filter. Just keep an open mind ♥

    1. 5

      What’s the reason for avoiding Yoda conditions? I see that there’s a way to get errors on assignments when a condition was intended, but I’m still going to be cold dead hands about them without knowing why.

      1. 8

        Why write in an awkward, contorted style to prevent a class of errors that the compiler/interpreter is perfectly capable of preventing? In Perl you just need to enable warnings, and in clang/gcc you can use -Wparentheses.

        1. 3

          Because the technique is applicable in a huge range of programming languages and environments, many of which don’t have tooling support to catch the error another way. That, and it’s only awkward and contorted the first time you do it.

          1. 4

            Even if you personally get used to it, it is contorted for anyone trying to read your code and slows the process down. And most other languages also warn or prevent it. In modern C, you need to put assignments in extra parentheses to avoid warnings.

            It’s a pity the Pascal approach of := for assignments and = isn’t more pervasive.

            1. 1

              I don’t think the contortion issue is that big a deal. I got used to it fast and I can’t see why anyone else couldn’t too. It’s not a new idea and it’s out there in loads of code bases already. There’s nothing inherently correct about putting the variable on the LHS, it just seems more common. This technique costs basically nothing and can prevent bugs. If someone reading code does a double-take when they spot a construction like that, good! It means they’re paying attention.

        2. 4

          This isn’t just a piece of Perl advice; anything that allows an assignment to occur in a conditional can potentially have the problem mentioned in the article, which is that you accidentally type an assignment operator in the conditional expression instead of an equality operator, and get a conditional that doesn’t actually implement the logic you wanted to implement.

          I’ve seen the same advice for working in C and other languages which allow conditional expressions on assignment. Having the left-hand side of the expression be something you can’t legally assign to (as the article recommends) is often the preferred style in such languages, in order to avoid the possibility of accidental assignment due to typo.

          1. 6

            It is silly though. People go out of their way and write funny looking code to defend against a class of errors that they are fully aware of. If you are aware enough to write conditions with Yoda style, you are aware enough too look there whe debugging.

            It also silly to combat a class of errors by reminding yourself about it every single time. How is that better than checking them all before compiling? At the point you think “I write this condition with this style because…”, Why don’t you just make that same thought exercise but put two double signs instead of one?

            Quite frankly, I suspect people do such sily things because it gives them a feeling of being “advanced” programmers. It’s an exercise of display of experience. I personally never felt any gain in such silly technique nor have I found anyone that came up with that themselves for their own interest, rather than having learned it from someone else.

            1. 4

              languages which allow conditional expressions on assignment

              … and which make the assignment operator a prefix of the comparison operator.

              1. 2

                Yes, I know why to use a Yoda condition, I’m curious why “avoid Yoda conditions […] you should.”

                1. 4

                  As far as I can tell, the reasoning in full totality is “they look weird”.

                  1. 3

                    The unstated assumption (which I think is uncontroversial) is that the common, standard way to write conditionals in most every language is if $var == val, so by using the yoda style you are just going against the grain for no good reason, making your code idiosyncratic. It’s not “bad” in any absolute sense…. it would just be like making weird but legal formatting choices, or using camelCase in a language whose standard style was snake_case, etc…

                    An invalid (imo) answer to your question is that the non-yoda style is more “natural” in some absolute sense…. which is like saying SVO or more natural than SOV word ordering.

                    1. 4

                      I don’t believe there are any absolutes at play here, like you mention, but it’s funny you bring up word order, because I think it’s precisely due to the predominance of subject-first languages that the variable-first order in conditionals is more intuitive, because I would guess that most people, in referencing a variable that way, model it as the subject of the conditional expression at hand in their heads.

                      Anyway, if it’s not something you already do intuitively, I don’t know why you’d adopt the practice when static analysis can easily guard against this case and others besides.

                      1. 2

                        I think it’s precisely due to the predominance of subject-first languages that the variable-first order in conditionals is more intuitive

                        Absolutely. Which implies that “more intuitive” here means “what you’re used to”. Which is also the reason to follow community standards, when they exist, which was essentially my answer to the question. It just makes it easier for everyone, on average. You can say, “But the accepted way is not more intuitive to me,” and choose to die on that hill, but as a general policy when working with shared code I think it’s wiser to give in, and in a few weeks the accepted way will probably start to look natural. The point is, all these things are arbitrary and habit-driven.

                        1. 2

                          In most natural languages (all?) The subject comes first when stating a comparison verbally. The subject is the fixed mental reference that is to be tested against a value and therefore we start by that. We start by what’s known. The value on the other hand is naturally put by the question signal (a question mark or descending melody) because is the part of the language that is subject to that doubt.

                          Note that, unlike latin languages, Germanic languages such as English often have qualifiers (adjectives) in front of subjects. However, not when asking a question. In that case the subject comes first and the “value” comes next by the question marker.

                          Yoda conditionals look weird because they are objectively conter intuitive. Sure, one can get used to it as with anything else.

                          1. 1

                            This got me curious. According to Wikipedia 87% are SOV (45) or SVO (42). 9% are VSO. Was surprised to find svo wasn’t the most common.

                2. 2

                  Perl::Critic should include this!

                  Assignment in an if() is problematic for readability. I’ve already been doing this as often as possible for readability.

                  1. 2

                    Reminds me of dev I would code review with. It was a large Java project where he would continuously put try/catch around everything making his code hard to follow. I told him “do or not do, there is no try”. Meaning just throw the damn exception if you’re not doing anything about it!

                    1. 1

                      Ah, that’s what these are called! I referenced this a month ago when someone was suggesting a similarly misguided (IMO) programming style to avoid forgetting break; in switch statements, in C++.

                      1. 1

                        I’ve actually encountered this type of error extremely rarely when writing Ruby. When writing Ruby I’ll intentionally do assignment in if statements to make the code more compact. It actually makes things easier to follow sometimes.

                        But I find = vs == extremely obvious in Ruby due to the use of keywords over symbols for syntax.

                        I don’t do this in JavaScript because this type of error is much harder to spot. Because I never do this intentionally in JavaScript = vs == shows up clearly in syntax highlight.