code size is not what you should be focusing on when refactoring. The key is readability and maintainability are, which are effected by code size, but code size should not be the be-all and end all.
– OrangesandlemonsApr 21 '17 at 9:37

2

That being said, imho the original version was more readable and self-explanatory :-)
– ScrontchApr 21 '17 at 12:14

1

Were the contents of the methods the exact same? Or did you simply have a big switch statement?
– Berin LoritschApr 21 '17 at 19:08

4 Answers
4

The problem with code duplication is, if you have cases where a change in one place always requires an analogoues change in another place, then you can too easily forget the change at that second place. This is what makes code really hard to maintain, and that is why it often pays off to remove duplicate code even if it saves you zero lines of code in total.

However, I suggest you try not to refactor in a way the readability decreases so much that you or your peer reviewer have doubts if this was really the right decision. In your example, I would replace your enum CoordSelector by something more self-describing like

You should not measure the result in how many lines of code you removed. Some valuable measures are the time you will gain when rewriting the code. If you need to make an adaptation, you will only need to adapt one method. Less time spent when rewriting the code, less time for someone new who is looking at the code, less time spent on bugs because the other method was not adapted...

The question you should ask yourself is-- did I reduce the number of code points that would require maintenance if I needed to change something? E.g. if you find a bug, will it be easier to apply the fix? If the code exists in two places, usually it is more work to fix (and to remember to fix it uniformly across the application).

Duplication can actually be better sometimes

Sometimes code duplication is actually better, e.g. if your system has a high number of dependencies and you are trying to improve the ability to deploy and update things independently. For example, if you have two microservices that need the same primitive string operation, it might be better to implement it twice rather than put it in a shared library, so that you can update each microservice independently without worrying about versioning the common library.