Interesting measure of code quality! I think it's the first time I see it.
Too often developers measure code quality by applying personal subjective measures, like number of lines per method, DRY or choice of programming language and start making major refactoring based on personal preferences.
If someone without knowledge of the code can swoop in and make meaningful changes, it does not matter how many lines of code there is or if it is built with X or Y. It's the end result that matters.
What I do see every day is "oh yeah, this method / file is pretty big, lets add one more thing to it anyways, I dont have time to refactor", and things grow and grow out of control.
I think one basic, and yet rare ability of a professional software engineer, and the skill that should separate you from a hobby programmer, is writing your code in a way which can scale and grow. The strategy for this cannot just be "let me put everything in one file, class, method and lets just see what happens".
That can be an OK first draft approach, but there needs to be a second step. And ultimately, if you set the architectural pattern of "big hairball", everyone else will happily follow it since its not their fault the architecture is like that - they are just adding one more thing. That can be OK for a first draft, but you will have to go back and introduce architecture and modularity at some point, or watch the project collapse under the weight of its own mess.
Once you see enough of those failures, you can start sensing basic patterns for introducing modularity, boundaries and structure to a project, to its modules, and to its classes and methods. As you keep flexing that muscle, in my experience, the "this code is best written as a huge single method" approach basically never seems like a good idea anymore.
How hard is it for a developer make this particular change?
And I mean literally observe this up close: navigating the directory structure, reading the docs, typing the code, running the app to check if everything works as expected.
Was it easy? What can change about the code, tests, docs, etc so future changes can be easier?
That's what really matters. Other measures are just proxies to the above analysis.
Honestly, my work place is filled with inexperienced people who have decided what the right approach should be. I'm older and more experienced than most and have learned that I can't win all battles, and bite my tongue when I see them making bad decisions. It's a form of age discrimination where even the management thinks that "young people see problems with fresh eyes". I don't want to come across as an "ok boomer" developer stuck in their old ways. "Rewrite everything in the new untested framework? Sure why not. The code is over 2 years old, so it's full of crusty legacy code".
I may seem a bit bitter in my comments, but I'm mostly disillusioned and are trying to see it as a learning experience. I'll give my opinion sometimes, and if they don't follow it it's not my problem. They will just need to learn the hard way and will probably end up in my situation in a few years.
I'm just collecting my pay check and planning to move on to a work place with more balanced demographics.