6 ms·
I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, wi
by Sohcahtoa82 3y ago
I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
- JonChesterfield 3y agoConsider (&& a b) and (|| a b) for no uncertainty over operator precedence and easy variadic representation (&& a b c) at the cost of zero additional parentheses.
- namrog84 3y agoWhile true and might be easy to read in the example context of a b c I'd imagine having the && separator in real world conditions to be far more readable and clear for vast majority if people
- TylerE 3y agoPipe looks far too much like a 1 or lowercase ell.
- trealira 3y agoI actually think the variadic logical and is more readable, and wish more languages had it. As long as all the arguments are lined up vertically, you can think of it as a sequence of tests for true that exits at the first failure. It's more obvious with the variadic operator. Contrived comparison: if (a != null && x != 0 && a.use_it(x)) { ... } (if (and (not (null a)) (/= 0 x) (use-it a x)) ...)
- NegativeLatency 3y agoMost, and possibly all languages I've used day to day do not have prefix operators like that.
- ant6n 3y agoPrefix operators considered harmful for readability.
- tasty_freeze 3y ago... at the cost of having parentheses around every subexpression.
- torstenvl 3y agoI hate Excel for this very reason.
- o11c 3y agoConvert them to arithmetic. If you ignore the casting, a && b is just a * b a || b is just a + b Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).
- dananabread 3y agoIs there an intuition for this correspondence otherwise I don't think it's very helpful
- dataflow 3y agoa * b * c is only nonzero if all of a, b, c are nonzero. That's AND, and should be pretty intuitive. a + b + c is nonzero if any of them are nonzero. (Remember each value is either 0 or 1.) So that's the intuition for OR.
- explaininjs 3y agoa+b+c is nonzero if any of a or b or c are nonzero.
- dataflow 3y agoYeah I just added that. I was hesitant initially cause you have to also note they're nonnegative, and that you're treating them like real numbers rather than mod 2.
- explaininjs 3y agoNatural numbers are the natural numbers for me! (ISO 80000-2, of course)
- naitgacem 3y agothis is the notation used in the chapters about boolean algebra in my digital design course. I think it's pretty neat. I honestly never looked into operator precedence in any language enough to notice the relation.
- userbinator 3y agoSorry, but I'm of the exact opposite opinion. If you don't know, learn. It's not hard (as other sibling comments have noted). Code with superfluous parentheses is even more confusing, since I expect them to be present only when overriding precedence. ...and I just realised your username adds some additional irony.
- sublinear 3y agoExplicit is better than implicit. I think the real problem is not breaking up complicated expressions. If it's more than just a few pairs of parentheses making it hard to read there's something more wrong there.
- thomasahle 3y agoI think most people agree "a*x**b + c" is more clear than "(a*(x**b))+c". Or "a+b+c+d" is more clear than "a+(b+(c+d))". Why are we happy to avoid parentheses for these operations but not for && and ||? Probably because we are all really used to the precedences for + and *. So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators.
- djur 3y agoMost people might agree with that, I don't know, but I know I don't think your first example is clearer. And I've had the operator precedence rules memorized for decades. Parentheses save my brain a step. The second example is irrelevant because addition is commutative so the parentheses are meaningless. (This is why languages shouldn't override + to be a concatenation operator.)
- tsimionescu 3y agoThe important part that makes the parens in the second operation unnecessary is that addition is associative, not that it's commutative. And concatentation is also associative, so even if those were strings, the parens would still be unnecessary. That is, (a+b)+c == a+(b+c). Interestingly, C integer addition is not actually associative, since (1+INT_MAX) + (-1) is UB, but 1+(INT_MAX+(-1)) should in principle be defined as INT_MAX.
- MaxBarraclough 3y agoThe Ada language requires explicit parentheses in the case of a succession of different logical operators precisely to avoid precedence-related bugs. [0] In the Pony language, any expression where more than one infix operator is used must use parentheses to remove the ambiguity. [1] The Zig language considered following Pony, but didn't. [2] [0] http://archive.adaic.com/standards/83rat/html/ratl-03-06.html http://archive.adaic.com/standards/83rat/html/ratl-03-06.htm... [1] https://tutorial.ponylang.io/expressions/ops#precedence https://tutorial.ponylang.io/expressions/ops#precedence [2] https://github.com/ziglang/zig/issues/114 https://github.com/ziglang/zig/issues/114
- pi-e-sigma 3y agoAda is such an underrated language. The lack of its adoption is a testament to the old adage that technologies don't thrive or die on their technical merits.
- MaxBarraclough 3y agoThe late arrival of a Free and Open Source compiler certainly didn't help its adoption in Free and Open Source circles.
- wruza 3y agoI remember reading a discussion on it in a year around <= 2000 and it was a general consensus that Ada’s printed standard is too heavy to move around, let alone implement. Military/corporate-ish affinity didn’t help either.
- pi-e-sigma 3y agoCompare C++ and Ada. C++ standard is an order of magnitude bigger and more complex and yet C++ is thriving. So Ada's failure definitively is not due to the language complexity. C++ has been supported heavily by the corporate, too. Biggest C++ champion was Microsoft, after all.
- MaxBarraclough 3y ago
- JohnFen 3y agoI know the priorities of these, but I still use parentheses to make the precedence explicit. I think it's just great practice -- and it makes things easier for the next dev who might have to work with the code.
- User23 3y agoYou’re in good company[1]: Do not introduce priority rules that destroy symmetry. I remember how much more pleasant the predicate calculus became to work with after we had decided to give con- and disjunction the same binding power and thus to consider p ∧ q ∨ r an ill-formed formula. [1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1300.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...
- thomasahle 3y agoThis article is a joy to read.
- Terr_ 3y ago> We don’t want to baffle or puzzle our readers, in particular it should be clear what has to be done to check our argument and it should be possible to do so without pencil and paper. This dictates small, explicit steps. I feel this justifies why I sometimes write code with lots of temporary variables on their own lines: It's a way to break down the problem, to name each thing (especially when it's not a simple method-call to a correctly-named method) and it also makes it easier to verify the behavior with the average line-by-line debugger or line-by-line debugging easier. In many cases, such temporary local variables have no negative performance impact, being optimized away.
- lifthrasiir 3y agoIt should be noted that this is not same to using a default order (typically, but not necessarily, left-to-right) in such case. Some languages use a term "non-associative" instead.
- moritzwarhier 3y agoIt bothered me a while for "short" boolean expressions to have a linter expect parens, where I'd simultaneously expect everyone with a high school degree to understand the implicit operator precedence. Then, since my first bug having been merged that was caused by a && vs || operator precedence mistake, I like my parens-always ESLint rule (or whatever exactly it was called). Even redundant parens can start to look as pleasent as indents, after getting used to them. In short, I think expressions like (a && b || c && d || e) are a footgun and linters should forbid them. Parens fit well with logical thinking, similar to relative clauses in language.
- asimeqi 3y agoI once implemented a logical expression evaluator to be used as filters on a search page. My boss tested it and filed a bug because he expected OR to have higher precedence than AND. I pointed him to a page with the rules and told him that he could use parenthesis if he wanted to modify the order of precedence. He was sort of convinced but never closed the ticket. Every release he would move it to the next release.
- paulddraper 3y ago|| is lower precedence than &&. I memorized that, just like I memorized that + is lower precedence than *. There are some languages (e.g. shell) where they have the same precedence. Prettier (JavaScript) adds parens like you suggest automatically.
- nealabq 3y agoSmalltalk doesn't have operator precedence rules. They just apply left-to-right. The infix operators aren't part of the language - they're messages (aka methods), and precedence would be inconsistent with the language's simple syntax.
- dehrmann 3y agoI'm always surprised when people don't know this one because they're like multiplication and clamped addition.
- Terr_ 3y agoAgreed, it's quite justified: If their implicit combined behavior isn't easy-to-read-obvious to the author composing the code, then it's also problematic for any poor future-person (perhaps even the original author) tasked with reading and verifying the code. Checking parens is faster than remembering and applying the knowledge. Plus the rules may be just different enough in different languages to trip up even those who try to remember them.
- zzo38computer 3y agoI also do (it also makes it more clearly, in my opinion), as well as with the bitwise operators & and | but sometimes with the bitwise operators the code is written in such a way that the precedence doesn't matter anyways and so I will not need to add parentheses anyways.
- torstenvl 3y agoDo you know the priority in this? [ -e "${target}" ] && echo "Getting information about ${target}" && stat "${target}" || echo "Failed to stat file." EDIT: What about the || die("...") pattern in Perl? Or the fact that the glyphs in || are visually lower than the glyphs in &&? Or that "and" comes before "or" in the expression "and/or"?
- pavlov 3y agoShell scripting sucks, but that’s hardly news. If I really have to touch a bash script, I just assume nothing works like I might expect from proper programming languages despite any surface similarity, and google every construct with sweat drops dripping down my face. ChatGPT has made the process somewhat more tolerable.
- PhilipRoman 3y agoThe shell command is very readable. a && b && c is a common idiom for "stop if any step fails". In the shell language && and || are more like control flow concepts, rather than binary operators. And a && b || c is a universal "ternary operator" (with one minor deviation) idiom across many languages, not just the shell
- cm2187 3y agoI just asked myself the question for SQL's AND and OR this week. Apparently AND takes precedence but I don't know if it is consistent accross all SQL engines. In any case it seems to me that few programers will know anyway, so it is bad practice to not have parenthesis.
- buserror 3y agoI do the same, not because I don't know the priorities, but because in my 35+ years career, I've seen so many times when cut+paste of partial expression leads to disaster just because it wasn't grouped properly with parenthesis.. Early in my career I erased several megabytes of shared memory on a mini computer, ie DOZENS of users worth of memory just because I was being 'clever' and cut+pasted bits of an expression the wrong way. Since then, as a rule, sod the priorities, parenthesis it is...
- dox_shepherd 3y agoThis is the best way in my opinion. Sacrifice a second of typing for clarity. I try to do this with expressions in general.