0

Occasionally I look at the code metrics in visual studio for my solution. I don't ever see anything I would find alarming. My maintainability is usually pretty high with exception to some obvious classes (entity config classes, DAL classes that call SQL, etc). The only time I really ever find the cyclomatic complexity and class coupling values high is again, on classes that I expect to see high values on.

If I were to look at code metrics after there is already a problem then I don't understand why I need to look, just fix whatever the problem is. Looking before there is a problem usually doesn't point anything out as the only low maintainability indexes are the examples mentioned above.

The only time I actually come into the code metrics for a reason is when I'm curious about how many lines of code the project is, and that's just because of curiosity and not a need to do so.

When is it useful to actually look at the code metrics of an ASP.NET MVC5 project/solution?

Improve this question
4
  • May I ask why there are close votes? Commented Jun 13, 2017 at 12:54
  • It would be useful to know what kind of architecture is being used and what type of application you are working on. Commented Jun 13, 2017 at 12:55
  • 1
    @JonathanvandeVeen, I don't think that's really relevant to the question asked. He only highlights some examples to show his understanding of the tool. Commented Jun 14, 2017 at 12:07
  • @Berin Loritsch: I think it is relevant to note that code metrics is more suited towards certain types of applications and certain architecture. That's why I asked. Commented Jun 15, 2017 at 6:19

2 Answers 2

Reset to default
5

Code metrics are simply sensors that indicate when something is out of an expected range. Taken in isolation, they really aren't that interesting as you point out, you can already guess at what it's going to tell you. They become more interesting when you start to compare trends.

This is one area where Continuous Integration/Deployment environments start to add value. You can at least compare the numbers from build to build and see if cyclomatic complexity is increasing rapidly for a piece of code--faster than what you might expect. It's an indication that perhaps the design might need some tweaking. Another thing that CI/CD tools do is allow you to set thresholds to let you know when something you aren't expecting to be high suddenly is.

The thing with any metric is that you can only manage what you measure. If you never measure anything you'll never know if there is something that needs to be looked at. It might be OK, but you need to look at it first. You can silence the alarm by adding ignore attributes for that inspection on specific code bases. Just make sure you add the "Reason" so that someone coming in after you (like you in 3 months) doesn't wonder why we turned off certain inspections.

Improve this answer
4

Code metrics are most useful for large code bases where you may not be able oversee or even know about each part of the code. Usually these situations happen when you have to work with code you have not written yourself. It gives you a good indication on problem areas in the code.

In your question I read that you have expected certain values at certain points. To me this is an indication of a certain pattern used in the design that leads to complexity being concentrated in certain parts of your code. Maybe the design could be improved to prevent complexity in certain areas. And maybe another approach would lead to less maintenance.

That being sad, you should keep in mind that these numbers are just a guideline to help you identify pain points before they become an issue.

Improve this answer
1
  • As far as expecting values in certain areas it's because I've noticed that maintainability values are always really low in classes like EntityTypeConfiguration<> instances where I can't really make those any more or less maintainable (at least to my knowledge). They are what they are. For instance my ProductConfig which is an EntityTypeConfiguration<Product> has a maintainability of 49 because of the many varying length nvarchar/string properties on the table/class. So I've just come to expect that those classes are most likely going to have a low maintainability index. Commented Jun 13, 2017 at 13:01

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.