Thus far, we’ve covered how to refactor our code in a safe, effective, reliable, and productive manner.
In this chapter, we’ll determine areas of code that might need refactoring using code metrics and code analysis tools. Along the way, we’ll cover the following topics:
The starting code for this chapter is available from GitHub at https://github.com/PacktPublishing/Refactoring-with-CSharp in the Chapter12/Ch12BeginningCode folder.
Every codebase I’ve ever worked with has had a few maintainability hot spots. These are areas that are frequently changed, have a higher degree of complexity than other areas of code, and represent serious quality risks to the software project.
These areas are usually some of the most critical to refactor and they tend to be easily discoverable using code metrics.
Code metrics calculate a handful of useful statistics about every file, class, method, and property in your C# code. This lets you spot hot spots in your code that have significantly higher complexity or lower maintainability. Code metrics can even help you find classes that are too large and likely violate the Single Responsibility Principle (SRP) as we discussed in Chapter 8.
To calculate code metrics, open your solution in Visual Studio and then click the Analyze menu, followed by Calculate Code Metrics, and then For Solution, as shown in Figure 12.1:
Microsoft knows that as C# and .NET changes, it can be very difficult to keep up with evolving standards in a broad and changing language.
To address this, Microsoft gave us tools beyond code metrics in the form of analyzers that inspect our C# code for issues. These analyzers look at our code and flag potential issues and optimizations. This helps ensure our code complies with standards and is secure, reliable, and maintainable.
To see an analyzer in action, build this chapter’s solution in Visual Studio and notice the three warnings that appear in the Output pane, as shown in Figure 12.4:
Figure 12.4 – An overview of the build results showing warnings
These three lines represent separate compiler warnings for the CS8618 code analysis rule, which we’ll look at shortly.
Before we do that, click on the View menu and then select Error...
The built-in code analysis and code metrics tools are very good for engineers wanting to pinpoint bad code and ensure code follows best practices for .NET projects, but they lack some enterprise-level features.
In this section, we’ll look at two different commercial analysis tools that I’ve found to provide additional value for .NET projects: SonarCloud and NDepend.
I won’t be covering how to set up these tools as both tools have comprehensive documentation that I’ve provided links to in the Further reading section at the end of this chapter. Instead, we’ll focus on the types of insights that dedicated code analysis tools can give you beyond what’s available in Visual Studio.
SonarCloud and SonarQube are a pair of commercial code analysis tools offered by SonarSource. Both products look at Git repositories containing code in a variety of popular...
Cloudy Skies Airlines knew they had a lot of technical debt and code issues, but they weren’t sure which areas they should prioritize. Each engineer had different opinions on what was most important. As you would expect, these opinions were usually influenced by what each engineer had worked on most recently.
To resolve this issue, engineering leadership turned to the data. They started analyzing the available code metrics in Visual Studio and cataloging where most code analysis warnings seemed to be located.
Engineering management then compared the problem areas with the areas that had changed within the past 3 months and the areas the organization expects will need to change to support the team’s upcoming initiatives. This approach helped engineering management prioritize technical debt resolution in strategic areas that supported business objectives.
To help resolve the backlog of warnings, developers were given a new...
In this chapter, we saw how code metrics and code analysis tools can help you spot problem areas in your code, follow best practices, and prioritize areas of technical debt. This will help you understand the issues you and your team struggle with. Once you know the areas you struggle with, you can focus on remediating them going forward. This also helps you prioritize areas of technical debt and communicate those areas to others.
These built-in analyzers are incredibly handy and it turns out you can build some on your own. Over the next two chapters, we’ll do just that as we build our own code analyzer that can detect and automatically fix issues.
Answer the following questions to test your knowledge of this chapter:
You can find more information about code analysis at these URLs:
© 2023 Packt Publishing Limited All Rights Reserved
