Site icon TAAGUNG

Measuring Code Quality with Visual Studio

Atul Sharma
Latest posts by Atul Sharma (see all)

If we google – “how to write good code”, we end up getting tons of articles. Over 90% of them talk about thousands of guidelines, which are never easy to follow and sometimes confusing. Most of the articles don’t talk about the measurement of code quality. Whatever we have read in our Computer Science curriculum has taken back seat, but relax, Visual Studio has taken very well care of this and provides the complete measurement of needed parameters for our code, project, and solution. Many developers are not familiar so thought of writing on this as a refresher for everyone. I follow SOUND for my code and code review, but still, that is not about code quality measurement.

How to run code analysis.

For this, you don’t need to do anything additional, no new extension installation. It comes by default with visual studio and you can access it from Analyze tab

Code Metrics from Analyze tab

and another right from solution explorer.

See also  BenchmarkDotNet: Advanced Features

And we get this window with all the needed parameters and values –

So we saw these parameters, their values now let us try to understand each of them in details. For this article, I have used Visual Studio 2019.

1.     Cyclomatic Complexity –

Cyclomatic complexity is a software metric used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code.

Wikipedia

Cyclomatic Complexity is calculated using control flow diagram. It uses following formula –

Cyclomatic Complexity (CYC) = E – N + 2

Where E and N are is the number of edges and nodes, respectively in the control flow diagram for a particular program.

If it is not clear to you, no worries, this simple example of comparing two numbers will explain this –

But if you are thinking, this is the simplest program and, in your assignments, you get the way complex program and it will be impossible to equivalent control flow diagram for everything you code. You are absolutely right. Visual Studio calculates this for you and here is output for the same example –

Important Points –

A lower number of CYC is recommended for any method. There is no strict guideline but based on different blogs and software scientist opinion, CYC can have these range –

  1. CYC < 10, is considered to be easy to understand.
  2. CYC between the range of 10-20 is complex but still comprehensive.
  3. CYC greater than 20 is considered very complex.
  4. CYC greater than 30 should be split into smaller methods.

Number of test cases for any method id directly proportional to Cyclomatic Complexity.

With this explanation, I hope you understand the Cyclomatic Complexity now and that was intention of this article.

See also  Visual Studio 2019: Limited Time Free Course on Pluralsight

2.     Maintainability Index

This uses a complex formula and as per MSDN –

Maintainability Index = MAX(0,(171 – 5.2 * ln(Halstead Volume) – 0.23 * (Cyclomatic Complexity) – 16.2 * ln(Lines of Code))*100 / 171)

If you don’t understand this formula, don’t worry. What we need to infer from here, I will explain in a few points –

  1. Its value ranges from 0 to 100.
  2. Higher the value of the Maintainability index, the more maintainable the code is.
  3. The range for them in visual studio is defined as follows –
Important Points –

And this is how, you see them in your code –

3.     Depth of Inheritance –

It shows the number of inherited classes, all the way from the base class. It doesn’t count the implemented interface. This diagram explains the complete story in detail –

And you see the same result for code analysis –

Important Points –
  1. Lower the number, more understandable, and easier maintainable.
  2. A higher number of DIT means a higher level of inheritance and in turn more breaking changes.  
  3. DIT > 7, should be avoided and classes should be redesigned, if possible.

4.     Class Coupling

It is also known as Coupling Between Objects (CBO) which is a means it measures the coupling and by principle, we know that coupling should be minimum and cohesion should be high.

 Here I have taken the example from previous.

Important Points –
  1. CBO only counts the number of unique objects referenced or directly instantiated in the method.
  2. Method2 has the object of class G, which has the highest DIT but still, it has CBO or class coupling as 2.
  3. As per MSDN – CBO has an optimal limit of 9, more than that could be very problematic.
See also  BenchmarkDotNet : Reliable and Efficient .NET Code Performance Measure

5.     Lines of source code –

This is a very popular and commonly used metrics. For measuring LOC we can have Physical Lines of code, Logical lines of code, and Comments line of code.

It will be clear from these two illustrations –

Example # 1 –

for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */

Example # 2 –

/* Now how many lines of code is this? */
for (i = 0; i < 100; i++)
{
    printf("hello");
}
 Example # 1Example # 2
Physical LOC14
Logical LOC22
Comments LOC11
Understanding Lines of code

No need to take these numbers as Visual Studio again takes good care of it and it counts Physical + Comments line of code for this metric.

Important Points –

It is count of blank lines and comments. Lower LOC is recommended.

Sometimes you can’t control the number of lines in a method and class but try to keep this as low as you can.

6.     Lines of Executable Code –

This metric counts the lines of code in generated MSIL code, you don’t have control over this. This is how it looks like in analysis tool –

Again, the lower value of this is recommended.

I hope this article helps you get a good understanding of various parameters of measuring your code quality and you will run this tool more frequently and restructure before it is too late.

Reference –

Exit mobile version