If there's something that I have learned about refactoring code that is repetitive into "cleaner" shorter code, is that the refactored version looks better but it's way harder to understand. When other people try to look at the "cleaner" version they have to spend more time trying to understand it and mentally untangle the abstraction.
I like syntactically shortcode as long as it's clear. I also understand that sometimes shorter code has some small performance advantages that can add up in languages like JavaScript where the size of the files can become a loading speed bottleneck.
But to be honest it really bothers me when someone tries to make perfectly fine and readable code into something different just to satisfy some weird intellectual urge to make things more abstract.
Sometimes long code is not only easier to read and understand, but it also helps to create a better technical outline of decisions that otherwise will get lost in the reasoning of whoever is writing that code.
It can be harder to understand; but, even worse, it can also be harder to change.
Which is a bit ironic, because if you asked one of us to explain why we "DRY", we'd probably say something about it making the code easier to change, because a change only needs to happen in one place.
The problem is that whenever you make abstractions, you necessarily limit your axes of flexibility, abstractions always have certain sorts of uses in mind, and built-in implicit limits. Abstractions make certain explicit things easier to change, while making all sorts of implicit things you haven't even thought of yet -- but which might come up later -- harder to change.
Still, obviously of course sometimes abstractions and DRY are the right thing to do. The trick is knowing which is which, which you get better at with experience at software in general as well as the specific domain -- and I'm not sure it can be systematized or formalized, I think it's still a craft.
> But to be honest it really bothers me when someone tries to make perfectly fine and readable code into something different just to satisfy some weird intellectual urge to make things more abstract.
They obviously don't think it's "perfectly fine" or that their changes are some "weird intellectual urge" or they wouldn't do it.
It's a subject for debate, and to make your case to that person, you need to do better than vague claims that what you're doing is "fine" and their idea is "weird."
This is by no means a generalization. You’re right. Most people are coming from a good place when they make suggestions that change your code. This especially true for code reviews where I believe everyone has the same goal.
I’m referring to some isolated cases especially those that involve receiving a codebase that was created by someone who is not working on it anymore. I think this is where that strange urge to refactor everything kicks in for some people.
I like syntactically shortcode as long as it's clear. I also understand that sometimes shorter code has some small performance advantages that can add up in languages like JavaScript where the size of the files can become a loading speed bottleneck.
But to be honest it really bothers me when someone tries to make perfectly fine and readable code into something different just to satisfy some weird intellectual urge to make things more abstract.
Sometimes long code is not only easier to read and understand, but it also helps to create a better technical outline of decisions that otherwise will get lost in the reasoning of whoever is writing that code.