Metrics could include: code style consistency, stability (has the area of code changed much over time), risk (is there potential for security vulnerabilities related to the code area), and test coverage.
The metrics - if displayed visually - might look something like a Heat Map[1], and would ideally be represented in the same place as the code itself, perhaps via background colours.
There is plenty of tools like this. I find them not very useful. They do not provide more value than standard project CI/CD setup eslint/jest/typescript/dependabot. These create a lot of false positives and act as rubber stamp for incompetent managers. Look our code is great, but we just failed to release for 4 weeks because of bugs and infra.
Best code quality measure is rate of defects. Tracking these and properly labeling issues by component would give better indication where to invest time into refactors/rewrites. In current climate good QA are rare and companies believe that devs can do everything.
If mature and reliable enough it could actually be used to predict which changes are likely to cause future problems, and then the code reviewer(s) would have to decide how they'd like to act based on that information.
Like some sort of generic reverse wireframe sketcher.
Like Hasura but not only for the data, or Microsoft Access but without Microsoft or vba.