Short but honestly good advise to rather pull boolean checks apart and re-group them as they make sense in the context of the given situation you’re checking for.
I started doing this when building an alert-check system for the company I’m working for right now, and it really helps organize what is a pre-condition, what a syntactical requirement, etc etc.
Good advice, clear, simple and to the point.
Stated otherwise: “whenever you need to add comments to an expression, try to use named intermediate variables, method or free function”.
Sometimes this can help, but lately I’ve been running into the opposite problem where people have been following this advice to such a degree that one cannot ever figure out what is going on without having to constantly jump around to find the actual code involved in doing something.
Ah I hate that, too. It speaks of bad abstraction, over eager abstraction or unnecessary coupling that is the hidden behind this. Difficult to fix though without essentially starting over.
I absolutely agree that method extraction can be abused. One should not forget that locality is important. Functionnal idioms do help to minimise the layer of intermediate functions. Lamda/closure helps too by having the function much closer to its use site. And local variables can sometime be a better choice than having a function that return just an expression.