10 November 2006

Code Metrics

Many people ask, if we are going to implement code metrics in ReSharper. Most people talk here about cyclomatic complexity, some mention maintainability index or even Halstead complexity measures. In fact, there are two major cases when people need code metrics.

One case is part of global measurement process in software development company. That is, when company measures and tracks requirements, design and architecture, implementation, tests, deployment, support and operations, etc. Obviously, this is out of ReSharper scope. It won't track history of measurements (as it doesn't track history of errors found in source code), it doesn't integrate with corporate database, it doesn't provide any help in fixing these measures. Someday this case will be covered by TeamCity, I think.

Another case is helping developer spot "code smells". This would suit ReSharper's nature perfectly, but why then just talk about code metrics? Why people want just "have a warning about too complex method", and not about "method belongs to different class"? Many of such "code smells" can be automated, and can aid developer in building Good Code. The problem with such warnings is that they often can give false positive. False positives are very frustrating, people will think something like this: "Well, I know, this code is complex. It should be. It was optimized for speed, implements complex algorithm and maintained by experienced Senior Developer. I DON"T want this warning here!". Thus, system that issues such warnings should have "ignore specific warning in specific place" mechanism, otherwise these warnings will be switched off globally most of the time.

I believe ReSharper team most likely will introduce suggestion system sooner or later, and then implement "code smells", including code metrics, and other useful suggestions that will help you write better code.

No comments: