Quote:
Originally Posted by kerowo
I've been trying to remember the rule about double negatives with and/or and can't so I prefer the positive logic. Seems like something the compiler would fix anyway.
The issue isn't performance, it's readability, which the compiler can not fix.
The rule for negation is called Demorgan's Law and you just negate them and toggle or/and.
!(a and b) = !a or !b
!(a or b) = !a and !b
And I think reasonable people can disagree which readability problem to prefer - you're trading off one for another.
However, it gets cleared the deeper you get imo. I rewrote some functions a year ago where someone had if statements 6 or 7 levels deep. They are now 1 level deep. It is very clear what gets to the end of the function and what does not.
Another principle I like but don't enforce is "all early returns should return an error condition, the only Good return should be at the end of the function"
Like in python you'll often be returning "None" for all your short circuit returns. Your real return will be, say, a dict of stuff. Return that at the very end and only there so people can know "this will return None or it will return a dict like this" and they won't have to reason about what state the return value might be in.