Jan Schreuder on .Net

.Net code samples, experiences, observations

View my professional profile on LinkedIn

Recent Posts

Tags

News

  • Inappropriate comments will be deleted at my discretion.

    The information and code samples in this weblog is provided "AS IS" without warranty of any kind, either expressed or implied, including but not limited to the merchantability and/or fitness for a particular purpose.

Community

Email Notifications

Tool suppliers

Tools

General

Microsoft

Favorite blogs

Archives

Code Complexity

A few months back, I tried to make a case for code inspections. So I was happy to find the following post on Michael Swanson's Blog at MSDN.

Michael Swanson helped manage the development team for NxOpinion diagnostic software. NxOpinion is a medical decision-support application. The team used some techniques from Agile, but also implemented formal code reviews and code metrics. During development, pair-programming (one writing code, one reviewing the code as it is written) was used. But they also held formal code reviews. They did this to educate people about the coding standards that had been agreed upon and to focus on improving the functionality of the code.

On a daily basis, an automated process would check out all the code and calculate the metrics. These metrics were stored as checkpoints. They were also used to pinpoint which code was a suitable candidate for code reviews. The higher the complexity of the code, the more likely it would be a candidate for a review.

A definite read if you're interested in code reviews!

In the comments on this post, you will find links to various (freeware) code complexity tools. I can recommend the community version of DevMetrics. I'm using it in my current project to pinpoint candidates for review and/or refactoring.

Comments

Dennis van der Stelt said:

What comments?! :)

And by the way, unregistered users are not allowed to post comments.

Agile doesn't mean you don't do code reviews and such. And pair programming doesn't mean you're doing XP. Even with Agile methodologies you can have quite some documentation, it's just that it's not written up front. Like Robert Martin says, when you write documents in concept phase or something, and specs (both technical as functional) change, the documentation is a drag to update and most of the time this doesn't happen. Result is a very complicated lie of what your system is, instead of the truth.

Source code is the best documentation you can find. Better make people able to read your code.

The metrics part to define when sourcecode is up for review is one most excellent method! I'll definitly try to implement that in some upcoming project. First, more holiday for me! ;)
# July 22, 2005 3:00 AM

Jan Schreuder said:

I love metrics as a way to see what code might need review/refactoring. I still see code from developers where one method will actually span 800 lines or more!!! I've even seen a class with just one method and that method was > 1000 lines of code... I've refactored it to a class with 20 methods, the largest of which is about 70 lines.

Enjoy the holiday Dennis. And I've changed my blog settings. Everyone can comment now!
# July 22, 2005 4:32 AM

Dave Frey said:

You're my first google hit for "code complexity .NET" and I look forward to trying the tool you mention.

I'm involved in a codebase that's begging for refactoring to the same degree you describe. Are you happy with how the tool "scores" your before/after?
# August 9, 2005 9:15 AM

Jan Schreuder said:

The scores before and after are great. Especially in the case where I refactored one method which spanned 900 lines into about 20 others. The code is easier to read and understand.
# August 11, 2005 2:36 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 5 and 8 and type the answer here: