A && (B || C)

Is there any way to get rid of the parenthesis?

I know how to remove the OR but the parenthesis are still there:

A && !(!B && !C)

A && B || A && C

but remember: parentheses are _not_ your enemy.

DeMorgans Laws

It will only make it more unreadable, store them in seperate variables if long expression is a concern.

@tosensei Thanks. My motivation is to make this more readable in code by putting each subexpression into a separate line like this:

return
A &&
B ||
C

(A, B and C are obviously placeholders for some expressions evaluating to Bool)

And the need for parenthesis destroys this idea because I don‘t know where to put them and keep it clear and readable.

Repeating A will also kill readability.

@IntrusionCM like I showed in the question itself, demorgan law doesn‘t remove parenthesis

@Demolishun that‘s a good idea! Thanks!

@Lensflare IMHO the original is readable well enough. don't overthink things ;)

@tosensei only because I‘ve replaced the real expressions with A B C 🙂

@Demolishun In my case, performance is not an issue. But if it was, I guess I could use a closure instead of an evaluated value:

let descriptiveName = { B || C }
return
A &&
descriptiveName()

@IntrusionCM started reading on DeMorgan -

The negation of a disjunction is the conjunction of the negations, the negation of a blarfgs is the disjunction of the jdwiqda of the disjckoea of the fniq2cwsc of theafa of thei ajdowa

:D

return A ? B || C : false;

Did I make it more unreadable?

@neriald clever :)
But yeah, I think it is less readable. Especially on multiple lines.

@Lensflare

Ok to be more precise...

What propositional logic does.

DeMorgan Laws are just additions.

I wouldn't recommend splitting terms - most of the times, the risk of an regression outweighs by far the pro of readability.

After all - if it's readable but plain wrong, it's wrong. :)

This applies especially to weak typed languages - where e.g. a logical operation can coerce the type implicitly... Lot's of good souls lost their sanity this way.

The variable way is usually the safest approach, as you don't change the equation at all.

@IntrusionCM yup, I’ll never work with a weakly typed language in my life again. I hate them with passion.

I see your point about a possible regression and I agree.

@Lensflare move the actual expressions to a(), b() and c(). This way you defer evaluation, hide complexity and have descriptive labels/method names. You can also hide C inside b() to get rid of parentheses

that's my go-to approach. And it's what clean-code suggests