New Ways to Be Told That Your Python Code Is Bad

For Turing's sake, if you insist on chaining ternary operators, then you should always use parens instead of showboating that you cleverly-by-half memorized a particular language's obscure precedence and associativity rules.

PHP in all its glory and splendor actually originally used left-to-right instead of right-to-left associativity for the ternary ?: operator, so that expression you wrote works differently in PHP and (JavaScript or C or any other language). (Side note: notice how I used parens instead of depending on you guessing about the relative precedence of "and" and "or" in English.)

It's easy (and perfectly valid) to blame the designers of PHP for not knowing or caring or paying much attention to the syntax of the programming languages they were imitating, and doing something that stunningly stupid, but it just goes to prove that many people (especially PHP designers like Rasmus "I don't care about this crap at all" Lerdorf and typical PHP programmers) don't even have the faintest idea what the precedence and associativity of many of their favorite programming language's operators are, or what those terms even mean, and they just willy nilly cargo cult copy and paste and translate between PHP and JavaScript code examples from Stackoverflow, introducing terrible hard-to-spot bugs.

https://en.wikiquote.org/wiki/Rasmus_Lerdorf

>"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf

But the real fault lies not just with PHP for parroting C incorrectly, but with C for doing something that stupid and hard to remember and easy to get wrong in the first place.

Please always use parens for that kind of stuff, because even if YOU memorized and love to depend on and show off your knowledge of the precedence and associativity rules of the language you're using, the people reading and modifying and maintaining your code probably don't.

https://wiki.php.net/rfc/ternary_associativity

>PHP RFC: Deprecate left-associative ternary operator

>Unlike most (all?) other languages, the ternary operator in PHP is left-associative rather than right-associative. The left-associative behavior is generally not useful and confusing for programmers who switch between different languages. This RFC proposes to deprecate and remove left-associativity for the ternary operator and require explicit use of parentheses instead.

>As an example, the code

    return $a == 1 ? 'one'
         : $a == 2 ? 'two'
         : $a == 3 ? 'three'
         : $a == 4 ? 'four'
                   : 'other';

>would in most (all?) other languages be interpreted as

    return $a == 1 ? 'one'
        : ($a == 2 ? 'two'
        : ($a == 3 ? 'three'
        : ($a == 4 ? 'four'
                   : 'other')));

>which is both the useful and intuitive interpretation. In PHP, it is instead interpreted as

    return ((($a == 1 ? 'one'
           : $a == 2) ? 'two'
           : $a == 3) ? 'three'
           : $a == 4) ? 'four'
                      : 'other';

>which is generally not what was intended.

https://stackoverflow.com/questions/20559150/ternary-operato...

>Q: Can someone please explain what is happening here and why it is printing 'four'?

>A: Because your whole expression evaluates as if it was (......) ? 'four' : 'other'. Since the first element is probably something truthy, it gives you 'four'. In saner languages, where ?: has right associativity, the whole expression evaluates as if it was $a == 1 ? 'one' : (......), where if $a is not 1, you go on to test other things.

http://phpsadness.com/sad/30

>PHP Sadness: Ternary operator associativity

>The ternary operator is left-associative and therefore behaves entirely incorrectly:

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

>PHP: a fractal of bad design

>Unlike (literally!) every other language with a similar operator, ?: is left associative.

Linters are good because they stop people arguing. Some early employee in the team defines some set of rules, and that's just the way things are from then onwards.

Less time bickering means more time spent doing actual productive stuff.

I hypothesise that the actual meaning (possibly subconscious) underlying those uses of "complicated", "syntactic sugar", and "clever code" is 'not the way I'd write it'; and that "clarity" and "clean" actually mean 'the way I would write it'.

To test whether those statements are guiding principles, or merely ad-hoc justifications, I propose the following pylint rules based on those principles:

    no-ternary-sugar:

      Replace 'x if y else z' with '{True: lambda: x, False: lambda: z}[y]()'.
      This is less concise, but improves clarity by using booleans explicitly,
      and making the delayed evaluation of the results clear; both of which are
      implicit in the 'if/else' syntactic sugar.

    no-elif-sugar:

      Replace:

        if foo:
          bar
        elif baz:
          quux
        ...
        else:
          foobar

      With:

        if foo:
          bar
        else:
          if baz:
            quux
          else:
            ...
            else:
              foobar

      This is less concise, but makes the branching structure clear, unlike the misleading
      "flat" appearance of the 'elif' syntactic sugar.

    no-special-case-patterns:

      Replace:

        if foo:
          bar
        else:
          baz

      With:

        match foo:
          case True:
            bar
          case False:
            baz

      'if/else' is syntactic sugar for pattern-matching a boolean, which is left implicit.
      Explicit matching improves consistency with other use-cases, and makes the relationship
      between branches and boolean clear, at the expense of conciseness.
      (Also applies to single-armed 'if', which will only have a 'case True:').

Of course, the combination of no-elif-sugar and no-special-case-patterns would give extreme clarity like this:

    match foo:
      case True:
        bar
      case False:
        match baz:
          case True:
            quux
          case False:
            ...
              case False:
                foobar

Still beats APL