Comment by danbruc
6 hours ago
Interesting that the amount of code remained essentially unchanged. In my experience it is not unusual that refactoring messy code cuts the number of lines in half.
6 hours ago
Interesting that the amount of code remained essentially unchanged. In my experience it is not unusual that refactoring messy code cuts the number of lines in half.
It can go both ways. Lines of code is a terrible metric for pretty much any goal that refactorings are meant to tackle.
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.
> What scenarios are there where the code is actually bad but refactoring does not reduce the lines of code?
IMX: the scenarios where people hold higher standards than what you describe :) (i.e. such that "the function does five things" is deemed "actually bad". Of course, that does depend on the refactoring not causing an unacceptable performance hit, which can happen depending on the environment.)
1 reply →
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.
A couple of days ago I split a single class which did 5 barely-connected things, where each of the 5 entry points had another 5-10 private helper methods (none of which were shared between entry points), into 5 separate classes which each do one thing - total number of lines went up (because they all have the same boilerplate import statements at the top), but being able to focus on one entry point and it's helpers at a time has made things much easier to work with
That's LOC in a single file, that's a bit different from total LOC as a metric.
Total LOC is a garbage metric. Things like reducing line count in specific files or components is a big benefit, but those lines are often moved, not dropped.
LOC can be one measure, but not always the sole or best ones.
Since LLMs are word generators, and have a propensity to generating words, they need to be shaped to understand simplest is best, more isn't more, and less isn't more always.
Trimming down and cleaning up could be formatting, standardization, commenting, or even some basic re-architecting that was overdue.
One of the biggest benefits of llms for refactoring I'm finding is reducing technical debt.
Yep, this was a real surprise to me, too. That’s why I included that top line in the figure. It also doesn’t line up with the agent’s predictions when it laid out the refactoring before proceeding.
There’s further work to do to understand exactly what’s going on here.
Yeah, I sorta expected the punchline to be "this 17,000 lines of code became 2,000" but it is still about the same quantity. Kinda interesting. Also interesting that the last change has by far the largest effect (4x reduction in tokens) and that also corresponded to the biggest reduction in single file LOC
Quality of lines > Quantity of lines.
In some projects, the code might not have much, or enough testing, or documentation/commenting.
Code is largely for others and the future if the creators of it want to move onto other projects.