Blogus Maximus

Rubbing people the wrong way since 1970...

  Home  |   Contact  |   Syndication    |   Login
  1366 Posts | 10 Stories | 2228 Comments | 1336 Trackbacks


Google My Blog

Catch me at: The List!

My InstallScript Utility Belt My Amazon Wishlist
My Standard Disclaimer

Tag Cloud


Image Galleries


Code Camps

CTown Geeks

Geeky Webcomics

High Geek

Magenic Blogs

Microsoft Blogs

My Articles

My Sites




I recently (tonight) installed the Release Candidate for VS2005 (I believe it was the September CTP.) After an absolutely PAINLESS install process, I fired up the HA! code and started taking a look around VS2005. (I have been using the betas all along, but I was curious about some of the features I don't normally use.

That's when I stumbled across the "Run Code Analysis on..." menu option. So I ran it on HA! and came up with some interesting results. Not necessarily surprising, mind you, but interesting. The one that really caught my eye was an error that indicated I had a cyclomatic complexity of 120 on one of my routines. If you're like me, you were probably wondering what that is exactly...

Cyclomatic complexity measures the number of linearly independent paths through the method, which is determined by the number and complexity of conditional branches. A low cyclomatic complexity generally indicates a method that is easy to understand, test, and maintain. The cyclomatic complexity is calculated from a control flow graph of the method and is given as

cyclomatic complexity = the number of edges - the number of nodes + 1

where a node represents a logic branch point and an edge represents a line between nodes.

The rule reports a violation when the cyclomatic complexity is greater than 25. (Oops! Mine was 120...)

It's worth mentioning that depending on how you write code, there are ways to generate a "false positive" on this type of error. One example would be when using a large Select Case statement. (You C#'ers call them switches, I believe.) Fortunately, VS2005 gives you the means to exclude or suppress this notification.

In the case of my code, the offending routine had no logic branches at all... just a handful of For Next loops and a boatload of direct value assignments to various points in an array. (It was part of my map initialization routines.) Based on the above formula, the cyclomatic complexity should have been pretty low, certainly under 25. Oh well, nothing is perfect.

posted on Monday, October 3, 2005 8:58 PM


# re: Cyclomatic Complexity in VS2005 RC 10/4/2005 6:06 AM Rick
At work, we use CodeRush which has a complexity metrics feature that is similar. They say that 200-300 is the top end of complexity, and we have some methods that are more like 6000 on their scale (I did not write them, but I do have to maintain them, and they aren't really that bad).

That should make you feel a little better, eh?

# re: Cyclomatic Complexity in VS2005 RC 10/4/2005 7:34 AM Chris Williams
Wasn't feeling too awful about it... :) But it's good to know I'm not alone.

# re: Cyclomatic Complexity in VS2005 RC 10/28/2005 4:33 PM Tim Shakarian (TSHAK)
Several loops, with logic within loops (even if they're not conditional), will correctly result in a higher cyclomatic complexity.

An interesting note: Once I started developing code test-first, I had insanely low cyclomatic complexity numbers (avg. 3, max 9) without even trying. It's amazing how much simpler code seems when it's loosely coupled and uses objects (OOP, what's that?) and well factored methods instead of TheBigHonkinMethodThatDoesAll(). :-)

Post A Comment