Skip to end of metadata
Go to start of metadata

Table of Contents

In the catalog of sins, a bad distribution of complexity may be most like the moral sin of gluttony. But instead of trying to cram too much food into his body, the developer crams too much logic into a method or class.

It's natural that a program will have some complex files and methods (just like it's okay to have dessert occasionally). but if you have too many of those, then what you may have done is code yourself a pot-full of spaghetti (to continue the food metaphor). Which means that the next coder who has to work on the application will have a hard time understanding what's going on in the code. And if she has a hard time understanding it, she'll have an even harder time successfully modifying it. 

Further, complex code can be hard to unit test properly. And if it's hard to unit test, then the risk of modifying it increases because you don't have that backstop against the introduction of bugs and regressions.

Analyzing Complexity

Complexity Widget

Add the Complexity widget to your dashboard:

And take a look at the distribution to see whether you have too many very complex methods or files. Ideally, the graph in the widget should be weighted to the left. Again, having a few files or methods on the left side is normal - particularly for larger applications - but too many and you've got a problem.

Finding high-complexity components

There are two ways to find high-complexity components. The first is to use the drilldown from the Complexity widget. The second is to add the Metric hotspot widget to your dashboard with metrics like complexity /file, complexity /method, etc to hunt for high-complexity components.

  • No labels