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.
I do OOP because it naturally encourages me to do this sort of thing: abstract complicated logic into inspectable, reusable, testable properties of an object.
I was expecting something more profound. Isn’t this just the concept of using variables to keep code readable? Not a new concept and likely one most devs learn early on.
I’ve had at least one code reviewer ask me to put all the logic in the
if ...line rather than use a variable or two in order to “simplify code by reducing the number of variables.”At the very least, this article helped me confirm my own bias of “that guy is a moron” and I can send this article to him the next time he reviews my code.
Well it actually depends.
Does it make the code more readable? Like you have several if statements using the same things (and/or else if)? Yeah then it’s probably good.
If you have an if (work.lengt() == 0 && stacked_work.length() == 0) and that’s it, probably not. Depending of whats happining then of course.
Be creative guys! But also dont be too creative :-) Think about the poor coder doing something with all that in a year or two, let’s make his life less miserable (It’s probably you, too).
“it actually depends”
Yes, it depends. But in this scenario we’re not discussing if statements with one or two conditions. We’re exclusively discussing multiple complicated conditions. :)
Yes, you need to push back on those people. They’re the type that get high on code golf and end up writing unmaintainable one-liners measured in kilobytes for fun.
Even though I like intermediate variables myself, I’ve been told the same thing when co-authoring code.
What these anecdotes suggest is that this is subjective, and I think it can be overdone. I don’t think objective general rules can be established from the article, even though I think it’s good advice.
In my examples, I was overdoing it and causing too many indirections, creating leaky abstractions (leaky because, in my context, the abstraction was not tightly self-contained and understanding the “implementation” of the abstraction was necessary to understand what the line of code that was using it was doing).
I don’t think it’s a black-and-white matter. Your reviewer might not necessarily have been a moron, or might have lacked the self-awareness to realize they were imposing their own preferences onto you. But there’s a slight chance that you legitimately confused them with your indirections. Hard to say without context.
This is “Testing on the Toilet” which are short flyers that are posted in bathrooms at Google. They aren’t typically meant to be particularly profound, just to remind people of common code patterns that can be written more clearly or other reminders that are good to keep in mind.
Good advice. The few pages of blog posts I have read are a really great read
The entire TotT series is pretty good.
Good advice, bad biology: mushrooms aren’t plants and therefore nor vegetables.
Vegetable is probably meant in the culinary use here, not in the biological one. And like with many such terms the two do overlap but not entirely.
I think it’s a bad analogy because it’ll distract some people.
I don’t think a lot of people think that mushrooms are vegetables in any sense. If you check culinary lists of vegetables, they don’t contain edible fungi.
I’d consider them vegetables for cooking purposes
Yes, I’ve been doing this for years. It’s great for both code readability as well as debugging.
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.
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.
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.
