Dan Miser - SourceMonitor

Tuesday, February 21, 2006

Someone on the newsgroups posted a linke to SourceMonitor. It is a tool that analyzes source code (Delphi, C++, C#, Java, VB, C, and HTML) and reports on various code metrics, like the number of lines of code, average statements per method, methods per class, depth of method, global routines and variables, cyclomatic complexity of a method and tons more. The charts are incredible (Kiviat graphs that are configurable with tolerance levels), and you can drill down and sort by any criteria. By doing this, you can identify methods that need to be refactored. In addition, you can View Source on the details and get buttons to take you straight to various offending code metrics (max depth, max complexity method, etc.). The detail view also shows graphs and more information about each unit. Lastly, you can take multiple snapshots so you can monitor progress of your source code's health over time.

This tool is listed as being freeware, but this is one instance where you get WAY more than you pay for.

Tuesday, February 21, 2006 1:04:00 PM (Central Standard Time, UTC-06:00)

Wednesday, February 22, 2006 12:04:00 AM (Central Standard Time, UTC-06:00)

Dan,

So Steve T. called me into his office this morning to show me this thing. He was VERY excited when he called me in and saying things like "this is SO cool". While I certainly agree that this tool would be a useful thing to have in the toolbox, I'm still missing the big picture. What I want to know is what it is about this tool that got you and Steve so excited? How exactly can it help you build better software?

Mark

Mark Edington

Wednesday, February 22, 2006 2:55:00 AM (Central Standard Time, UTC-06:00)

I think I agree more with Mark here. I'm not sure I would use much of this data unless I just want to find long metods to refactor just to be busy refactoring or remove global variables just because they are bad. I'd prefer a static analysis tool that can find "real problems." There are several of these for C code, but no good ones for Delphi, as far as I know.

I once saw a program that would find duplicated code in a Delphi application (it allowed differences in formatting and identifiers), and I think it was a lot more useful. I don't remember the name right now, though.

For Delphi code, tools like EyeBol and Pascal Analyzer can at least give me hints that might (sometimes) be actual errors in my Delphi code.

Erik

Wednesday, February 22, 2006 9:21:00 AM (Central Standard Time, UTC-06:00)

The 2 metrics I think are most useful are complexity and statements per method (max depth is also a good one). If you have a method with a complexity of (e.g.) 190, it would be rather good to identify that method for further evaluation and refactoring. The same goes for a unit/class that has average statements per method of 350.

In short, it gives me a place to start looking based on metrics, as opposed to haphazardly encountering a method/class with bad "code smell".

My thinking is if something triggers a red flag in this analysis, then it will be a red flag in compiled code. For example, if you have a method with complexity of 190, you would need 190 unit tests to ensure complete code coverage of that method. I don't know about you, but I would sleep a lot better if I know that the code is more maintainable, more extensible, and more correct vs. relying just on QA to go through all 190 permutations in calling that method.

Dan Miser

Comments are closed.