alt Hacker NewsIt can go both ways. Lines of code is a terrible metric for pretty much any goal that refactorings are meant to tackle.
Replies
I don’t know. LOC to me is indispensable for certain refactoring goals in my opinion.
Taking a component and turning it from 7K lines to 3K lines and maintaining functionality obviously means there’s less complexity introduced, less to go wrong now, and less overhead to modify in the future.
Sure it can go the other way, the component needs to support something it might need, we need to adjust larger patterns, this function needs to be refactored into something more robust.
But lines of code is a pretty decent metric of success for “trimming down and cleaning up” style refactoring, to me at least. It’s not everything of course, but it’s definitely an indicator.
I did not mean it as a metric but as an indicator what was wrong with the code.
- the code is essentially good but all is in one file, you split it up, lines of code stay the same
- the code is essentially good but lacks some structure, for a function that does five things directly, you extract the functionality into five functions and call them from the original function, lines of code goes very slightly up
But once the code is actually bad - code duplication, bad abstractions, inefficient language use, ... - I would generally expect the lines of code to significantly drop. What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code? It is certainly possible but at moment I am having a hard time comming up with a good example.