Hacker News Reader

Comment by sverhagen | Hacker News Reader

Yeah, as if a line with condensed conditional logic using Boolean operators really got rid of the branching and the running it through your head.

My attempted better advice would be to keep methods short and the nesting/indentation limited. Use good method names. Make it easy to understand each method in isolation.

View on HN

I guess if you’re not familiar with Boolean operators that would be a thing?

Seriously are you saying that

    if (x) {
        return y;
    } else {
        return false;
    }

is as easy to read as

    return x && y;

Huh, is this python-style logical evaluation, i.e. "x && y" need not be a boolean but could be whatever "y" is?

Regarding which way is better, there's not much benefit arguing one way or the other. This is a leaf decision. It doesn't affect the structure of other parts of the code.

I'm curious, what about "x && y" is "python-style" ?

It's been in nearly all languages, and for decades before python existed.

It was not about "x && y" but about the construct from the parent post as a whole. It never uses y in a boolean context, but only as a value. So I was thinking y could be anything. In python this is how it works:

    >>> 0 and 'asdf'
    False
    >>> 3 and 'asdf'
    'asdf'
    >>> 3 and ''
    ''

'and' and 'or' in python are short-circuited as in e.g. C, but it's even more short-circuited! The "last" component is not evaluated in a boolean context. For a complete evaluation you have to use the expression in an if or while statement or apply the bool() function. I would say it's like a monad, if that helps.

What you are talking about has nothing to do with short circuiting.

Agreed, bad choice of words. It's only somewhat similar. Maybe "lazy" would be a better term. Whatever, man! I hope it's clear what I meant.

It’s not that you’re unclear, it’s that it is irrelevant to the discussion, as you were talking about a fairly trivial and unrelated language feature — and it is also a feature that exists in many languages, hardly unique to python.

Whatever, man. Maybe it was not totally related. Agreed. Maybe I had a bad day. It started as a single line that wasn't even the point of my comment. Ok?

The former can be understood by anyone with a basic grasp of English grammar, while the latter requires understanding the Boolean operator. So yes, the former is more readable.

If someone doesn’t have a basic grasp of Boolean logic then maybe programming is not the right choice..

Earnestly: Yes. But there may well be programming tasks or jobs that they are suited to, for which no understanding of boolean logic will make no difference on a day to day basis.

Doesn't matter. Unless one option leads the compiler to generate better code than the other, it's a matter of aesthetics, not correctness. And since you don't even need to be a programmer to understand what the first one means, it's still easier to read.

An observation that comes from studying foreign languages: you learn “and”, “or” and “not” a long time before “if”.

Borrowing the variable examples from another comment, do you believe that the former is easier to understand for someone who knows English grammar than the latter? (I'm using Python syntax since we're going for English-like readability and added parantheses to the boolean operation to indicate order of operations for the liberal arts major that we've decided is the target audience of this code):

  if isAdmin:
    return false
  if not isActive:
    return false
  return true

  return (not isAdmin) and isActive

I agree, there shouldn't be any argument on boolean logic being easier than the branching logic. The other examples are more discussion worthy.

No, but:

    if (a) return false;
    if (!b) return false;
    return true;

May be easier to read than:

    return !(a || !b);

But is it easier than

    !a && b

? :)

Seriously, it took me something like 10 seconds to parse your parent post. How a negated chain of if else would ever be easier to understand than a much simpler !a && b really defies my understanding...

What about:

    return a ? false : b;

I still prefer the Boolean logic version.

I’m a heavy user of ternary, but it’s still an “if”. And and Or are (not very much) higher-level operations.

I was being mostly facetious.

Rename a and b to reasonable names:

a -> isAdmin

b -> isActive

    const isDeletableUser = !isAdmin && isActive;

    return isDeletableUser;

(Better would be naming the function "isDeletableUser" instead of the intermediate const, but was keeping with the original.)

Point is for me that booleans with readable names shows how eliminating ifs becomes not only doable but arguably preferable.

De Morgan laws are seriously your friends when trying to make complex boolean expressions optimally readable.

I'd definitely say it was. The branch is much clearer and more explicit.

Branches are often important things to consider such that hiding them inside in-line conditional expressions can make a code reader miss a key piece of logic. Use in-line branches with caution.

Depending on the language and values, the latter does not mean the same thing.

    <?php
    $x = 1;$y = 2;

    function test1($x, $y) {
        if ($x) {
            return $y;
        } else {
            return false;
        }
    }

    function test2($x, $y) {
        return $x && $y;
    }

    var_dump(test1($x,$y));
    echo "\n";
    var_dump(test2($x,$y));

Since we’re discussing readability, let’s be generous and assume the code behaves the same.

Since otherwise, it’s not a question of readability anymore. (But yes, incorrect transformations are incorrect.)

I agree with you on the keep indentation / nesting limited, but I am not a big fan of splitting things into short methods for the sake of it. Provided indentation isn't going too deep I often find it easier to read things in a script like manner instead of jumping in and out of lots of shortish methods.

Reply on news.ycombinator.com