It's better than SLoC, but it's still not good.

Trying to quantify the quality of a code base is pointless, impossible, or both.

Consider this. A perfect piece of code (from an engineering standpoint) has these characteristics:

    - Free of bugs (serves intended purpose)
    - Never needs to be modified
    - As short as above characteristics allow
    - As efficient as above characteristics allow

If you make these assumptions, hits-of-code indicates poor quality. It shows that the coder introduced bugs, failed to foresee what the code would need to do, or just didn't write it concisely or efficiently enough.

But because we'll always have to fix bugs and modify code, a more realistic set of characteristics is this:

    - Easy to fix bugs (readable, well-organized)
    - Easy to learn (see above)
    - Easy to make changes

It's a completely different list, but hits-of-code still might indicate poor quality. It might mean that the coder is constantly refactoring, which means there will be more bugs and more learning time for other people working on the project.

Or, it might mean that the coder is trying to expand the feature set of the code. If you subscribe to the Linux philosophy, the broader the scope of functionality, the worse the code will get.

My point with all this is that "amount of effort" doesn't tell us anything about a code base. A great coder will do something in 10 commits that a terrible coder will do in 100.

The best metric I can think of right now is "how many users are touching this code". That tells you how useful the code is and how much work it is saving people. That's the core purpose of software: doing some work to save a much larger amount of work in the future. How do we measure that instead?