7 ms·
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
by sverhagen 8y ago
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.
- moomin 8y agoI 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;
- jstimpfle 8y agoHuh, 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.
- hellofunk 8y agoI'm curious, what about "x && y" is "python-style" ? It's been in nearly all languages, and for decades before python existed.
- jstimpfle 8y agoIt 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.
- deleted 8y ago[deleted]
- hellofunk 8y agoWhat you are talking about has nothing to do with short circuiting.
- jstimpfle 8y agoAgreed, 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.
- hellofunk 8y agoIt’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.
- jstimpfle 8y agoWhatever, 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?
- krapp 8y agoThe 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.
- tigershark 8y agoIf someone doesn’t have a basic grasp of Boolean logic then maybe programming is not the right choice..
- HolyHaddock 8y agoEarnestly: 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.
- deleted 8y ago[deleted]
- krapp 8y agoDoesn'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.
- moomin 8y agoAn observation that comes from studying foreign languages: you learn “and”, “or” and “not” a long time before “if”.
- ummonk 8y agoBorrowing 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 vs return (not isAdmin) and isActive
- carlmr 8y agoI agree, there shouldn't be any argument on boolean logic being easier than the branching logic. The other examples are more discussion worthy.
- d--b 8y agoNo, but: if (a) return false; if (!b) return false; return true; May be easier to read than: return !(a || !b);
- moomin 8y agoBut is it easier than !a && b ? :)
- tigershark 8y agoSeriously, 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...
- ballenf 8y agoRename 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.
- matthewmacleod 8y agoI'd definitely say it was. The branch is much clearer and more explicit.
- tabtab 8y agoBranches 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.
- deleted 8y ago[deleted]
- TooBrokeToBeg 8y agoDepending 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));
- moomin 8y agoSince 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.)
- collyw 8y agoI 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.