Documentation of the code metrics of the Tech Debt Tracker extension for VSCode.
We've picked a few metrics that are well-known indicators of code that could use cleaning up and that are predictive of bugginess.
These metrics are meant to guide your refactoring efforts and help you determine how to clean up the code. We don't recommend obsessing over them and making sure every piece of code is green with respect to every metric.
Keeping functions small helps write concise, simple code that doesn't do too many things and is easy to understand by engineers who didn't write it.
(Note that for JSX the ranges are 0-39, 40-89, and 90+.)
These thresholds are based on the idea that functions should fit in your head and you should be able to read the code without scrolling.
If a function you're dealing with is too long, try to break it down into simple components that can be combined together.
Limiting the number of independent paths in a function helps write simple code that can be easily understood without having to build a big mental model of all its intricacies. It's also less likely to contain bugs.
We use [typhonjs-escomplex](<https://github.com/typhonjs-node-escomplex/typhonjs-escomplex>) to compute complexity.
These thresholds are based on the Software Engineering Institute report (pages 145-149).
If a function you're dealing with is too complex, try to break it down, de-duplicate code, and wrap functionality that is not directly related to business logic into helper functions.
Functions that are easy to understand can be modified more quickly and with less risk of unwanted side-effects. For this metric, we are using "Halstead Volume" (part of the Halstead complexity measures) which measures how much information a reader of the code potentially has to absorb to understand its meaning.