Hacker News Reader

Comment by zootboy | Hacker News Reader

> less code is better than more code

Not when it's at the cost of readability. The example "better" code fails my readability test horribly. I'd gladly take C's ternary operator over this monstrosity:

> x = 4 if condition() else 5

View on HN

What's so monstrous about it? It's practically English:

    cssClass = 'selected' if isCurrentTab else 'deselected'

Probably b/c Python abuses the same keywords way too much. (But that shouldn't be such a surprise already to oppose this particular case.)

You have a weird perception of English. "If the tab is selected, the CSS class is 'selected', else it's deselected.

Or in pseudocode

    if isCurrentTab
      cssClass = 'selected'
    else
      cssClass = 'deselected'

Even ternaries read weird. "css class is current tab HUH?? selected COLON! deselected"

“Set css class to ‘selected’ if it’s the current tab, or else ‘deselected’.”

Both read grammatically fine to me. If you prefer to do things in 4 lines rather than one, and repeat the variable, that's up to you I guess - a lot of people seem to agree - but honestly I don't get what the fuss is about.

Exactly. I prefer this a lot more to at least avoid using else:

  x = 5
  if condition():
      x = 4

No, that's not good. If condition() is true, x shouldn't take the value 5, even temporarily. The combination of

  (x = 5, condition())

is inconsistent state (using the word "consistent" in the same sense as the C in ACID).

It really is clearest and safest to avoid inconsistent state, even if is only transient. There are so many ways programs can be wrong; no need to deliberately create inconsistent state when there's no need to.

In your version, we need to check the definition of 'condition', to see whether the 'x = 5' statement has any affects on its execution. The ternary won't assign the variable until we know its value.

Also, your version isn't safe to use with objects (e.g. 'myObject.x = ...'), since the initial assignment could trigger arbitrary code (properties, __setattr__, etc.).

Also, your version isn't safe to use when the right-hand-side has effects, e.g.

    x = fetch_config_url() if remote else read_config_file()

Can't be used in list comprehension either

My favorite way to write that is with expression oriented langauges. Example in OCaml:

    x = if condition() then 5 else 4

I dislike how the regular order of if is changed when used as an expression. I don't know how you could retrofit that into existing Python tough. Probably a consequence of defining blocks with whitespaces.

Yeah, Python's willingness to break up conceptual concepts into separate parts of an expression such that you might need to backtrack while reading has always seemed an odd choice to me, exemplified by list comprehensions, especially when nested.

It is simply a design choice, the common value is given first. Comprehensions in Py are the same.

Sure it's a design choice but, quoting the Zen of Python:

> Special cases aren't special enough to break the rules.

> There should be one-- and preferably only one --obvious way to do it.

Both are broken by the existance of 2 if syntaxes depending on the context.

But when you write "condition ? first : second" or "(if condition first second)", the first common value is still given before the second uncommon value, so what's the advantage of putting the condition BETWEEN first and second, instead of BEFORE? After all, the condition has to be EVALUATED first before deciding which one to use.

Infix "if" conditions just scramble up the order of evaluation from the order of program source code.

The argument is that the most common value should be first and the rest can be thought of as rare and almost ignored. I don’t always agree, but still prefer it to C syntax which I have to look up every time.

To add to the cacaphony of counterarguments to this, this can introduce nonobvious bugs when refactoring.

If the condition-guarded statement is nontrivial and you remove the assignment, everything stays valid. If otoh you use a ternary or

    if x:
        y = 1
    else:
        y = 2

If you now delete the else block or something (like the assignment from a larger else block), a linter can warn you that y is undefined. Otherwise you'd need a test to ensure correctness.

Honestly, the Python version is far more readable to me than the C, and that's even with close to a decade with C before encountering Python or any other language using that style.

Though Ruby’s unless modifier is often slightly better for readability.

In C, I always put the ternary clauses on their own lines prefixed with the operator. This always makes things readable.

    int result = condition
        ? value * 12
        : something_else();

and in the case where the condition is sufficiently complex:

    int result =
        (
            some_condition()
            && another_condition()
            && yet_another_condition()
        )
        ? value * 12
        : something_else();

For me, at least, this is entirely readable. The unfortunate bit is that there is no formatter in existence (yet) that can handle this for C, or really any other language with similar syntax.

Python's "Black" formatter actually does the best job here, yet the python ternary syntax is still very verbose and strange IMO.

> The unfortunate bit is that there is no formatter in existence (yet) that can handle this for C, or really any other language with similar syntax.

Prettier does it fine for JS, which uses C-style ternary syntax.

> Python's "Black" formatter actually does the best job here, yet the python ternary syntax is still very verbose and strange IMO.

To me, its quite natural when used sensibly, since if you drop everything after the if it is the normal-case value. Though I would slightly prefer if the ternary form was:

  <default-valur> unless <alternative-condition> then <alternative-value>

instead of:

  <default-value> if <default-condition> else <alternative-value>

Prettier does okay, it has some weird edge cases though that make certain code entirely unreadable. But they're rare. I still prefer how Black does things, e.g. splitting complex expressions into multiple lines using parenthesis.

> Though I would slightly prefer if the ternary form was:

Agreed, I do like that much better too.

Agreed - relatedly, I really dislike one-liners in code because more often than not, it's done for the sake of being "clever" rather than having readable code for the next person to quickly skim and understand.

I get that it's a "flex" or some sort, but honestly in production code my experience is that it reduces productivity. Programmers need a little more squinting to truly understand what that piece of code is doing.

I find it similar to run-on sentences in books - we don't like that, and in Business Writing courses they explicitly say to not do that. Code should be similarly readable.

> I really dislike one-liners in code

So...you should do more per line, since code is all one-liners, its just a choice of how many, so if you don't like them, you should reduce the number?

Helper variables have a serious place in growth phase, when you typically have lots of new devs and lots of bad code.

$user_authenticated = hmac_auth($_get['token']) === true || ldap_check($username, $config['ldap_restrictions']) || verify_credentials($_post['user'], $_post['pass']) === true;

Sorry for the php pseudo code, I'm on mobile. And this is a very friendly example of what I'm trying to get across. It's self documenting code and worth the extra bytes.

I've seen way too many insane conditionals to agree that less code is better.

I don’t think this criticism is valid for Python specifically where the most Pythonic expressions, generators of all forms, are read front to back like this.

    [ x.attr for x in list if x in someset]

There are languages where this kind of thing would be considered ugly and you’re supposed to use map/filter but in Python they’re the best practice. Every Python programmer is already trained to read expressions like this.

If a one liner is preferred, what if it could be:

if condition(): x=4 else: x=5

Yeah I don't like them as implemented, because most of my 'if' statements are in response to unforeseen things, so my mental expansion of it is 'Now, stop and check if...'

I wouldn't mind it so much if I could write it as:

  x = 4 unless shenanigans(); then x = 5

Yes, that is a semicolon. Fight me.

That's PERL right there.

Makes way more sense to my brain to read:

print unless $x ~ /end$/;

then

print if $x !~ /end$/;

I used to get flack for using not just if expressions as ternaries, but also for using unless. Then I started teaching PERL at my company and drilled it into all the fresh new minds.

I gotta be honest and say I like Python because it only has a limited amount of punctuation.

Also worth remembering that a perl statement can be converted into an expression with a do block, so you can write

    my $x = do {
      if (foo()) {
        4
      } else {
        5
      }
    };

(and yes, I know, that example would look fine as a ternary - but this is meant to illustrate the syntax possibility, not where I'd specifically use it - and once the logic within one of the two conditional branches gets more complicated, switching to do+if+else can make for clearer code)

I had a good chuckle as while reading this comment I was thinking "oh, I saw code like that just last week while reading SQL::Abstract's source", and then I saw the username. :)

Guilty as charged :D

What the... ? Why is that worth remembering? Just reading that code makes me feel dirty, let alone deploying it! ;-)

Sometimes the logic in at least one of the arms of the if/else is sufficiently complicated to make it worthwhile (e.g. cases where you find yourself needing a 'do' block inside a ternary).

Also doing that with if/elsif/elsif/else is often far more readable than nested/chained ternaries.

Exactly. I pretty much love everything about Python except its ternary operator. I also prefer C’s.

When I first started using python, I assumed it had a normal (c-like) ternary operator and was a little surprised to discover the syntax we're talking about. But after some time, it actually feels very natural to me, and is arguably more intuitive than ?: syntax. I assume this is where the author is coming from.

Arguably? It can be read like a sentence. ;-)

I assume they're talking about the meaning, not how you spell it.

So you can read both as a sentence. The arguable part is more about "condition and then thing" versus "thing if condition".

I'm really not seeing what's illegible about this?

For the cost of 4 extra characters, this line tells you exactly what it does even if you've never seen Python in your life.

Reversing direction is annoying to suddenly have to.

Reply on news.ycombinator.com