Hacker News new | ask | show | jobs
by jka 1968 days ago
A way to surface code quality -- across various metrics -- at any level of code (individual token, line of code, file, directory, package, library, application, ...).

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.

[1] - https://en.wikipedia.org/wiki/Heat_map
3 comments
Chyzwar 1967 days ago
Examples: Code Climate https://codeclimate.com/ SonarQube https://www.sonarqube.org/

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.

link
jka 1968 days ago
(in fact, resource usage efficiency for each code area could be a helpful metric too; CPU, memory, network, etc)
link
lumpa 1968 days ago
So either IDE and/or repository would show these? Sounds very useful and somewhat straightforward (if involved) to create, so I expect it to exist in some form. Will report back if I find anything.
link
jka 1967 days ago
Yep, it wouldn't be too surprising if it does already exist. It'd also potentially function something like a more advanced diff tool that can provide time-saving efforts to those who use it.

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.

link