Message-ID: <960407817.1027.1429985997356.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1026_411742293.1429985997347" ------=_Part_1026_411742293.1429985997347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In the catalog of sins, a bad distribution of complexity may be most like the moral sin of glutto= ny. But instead of trying to cram too much food into his body, the develope= r crams too much logic into a method or class.
It's natural that a program will have some complex files and methods (ju= st like it's okay to have dessert occasionally). but if you have too many o= f those, then what you may have done is code yourself a pot-full of spaghet= ti (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 goin= g 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 mod= ifying it increases because you don't have that backstop against the introd= uction of bugs and regressions.
Add the Complexity widget to your dashboard:
And take a look at the distribution to see whether you have too many ver= y complex methods or files. Ideally, the graph in the widget should be weig= hted 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.
There are two ways to find high-complexity components. The first is to u=
se the drilldown from the Complexity widget. The second is to a