Remove unused classes, properties, and functions

The next step I want to do is remove any unused classes, properties, and functions. If you don’t do this, you may spend time doing other refactoring on things that aren’t used – which is a waste of time.

NOTE: The code analysis tools below aren’t perfect. Sometimes, they say something isn’t used when it actually is used. Common things that are missed are properties in XAML and parameterless constructors used for deserialization.

Here are two ways to find unused classes, properties, and functions.

Visual Studio Code Analysis

In Visual Studio, you can create a custom “ruleset”. This is where you define the code issues you want to know about.

Unfortunately, you can only detect unused private members. This is because the code analyzer assumes public members might be used by other programs. This could be true if you’re publishing them as an API through a web service or releasing your code as a library.

With this program, the only projects using public classes are other projects inside the same solution. So, we can safely eliminate unused public members in this program. We just can’t find them through Visual Studio rulesets.

To find unused members with a Code Analysis Ruleset, from the Visual Studio menu select File -> New -> File… -> General -> Code Analysis Rule Set.

Uncheck all the rules. There are many rules we don’t care about right now – and some we probably won’t ever care about. As we clean the code, we can add more rules to check for.

In the search box (upper-right of the tab) search for the following terms (without the quotes). Check all the rules you see listed for them. Or, you can search for the following rule numbers: CA1801, CA1804, CA1811, CA1812, CA1823, and CS8020.

“unused”

“uninstantiated”

“uncalled”

Save ruleset file. In this example, I used “MyRules.ruleset”.

Right-click on the Engine project, in the Solution Explorer, and select “Properties”. On the Properties screen, select “Code Analysis”. Check “Enable Code Analysis on Build”, to have our rules checked every time we build the project. Click on the “Run this rule set:” combobox, select “<Browse…>”, and select the ruleset file you created.

Now, when you build the solution, you should see an “Error List” tab that displays any code that breaks a rule in your ruleset.

ReSharper Code Analysis

ReSharper has similar code analysis functions – with the advantage of checking for unused public members.

To run ReSharper’s code analysis, from the Visual Studio menu, select ReSharper -> Inspect – Code Issues in Solution.

This showed me 171 issues in the code. For this step, I only want to correct for unused classes, properties, methods, parameters, and variables. So, I selected “Issue Type and File” in the “Group by:” combobox and saw these results:

I checked “Class is never instantiated”, “Type or member is never used”, “Unused local variable”, and “Unused parameter”.

You need to be aware that this report is not perfect. ReSharper claimed Program.cs (from the SuperAdventureConsole project) is never used. It’s true that nothing else in the solution calls it. However, if you set the console project as the startup app, Program.cs is definitely used.

Double-check everything before making a change based on either code analysis tool.

Combined code analysis results

The two code analysis tools identified a few refactoring changes I made.

Engine\Models\Player.cs

Removed unused “currentLocationID” parameter in CreatPlayerFromDatabase. This required a change to PlayerDataMapper.CreateFromDatabase(), which called Player.CreatePlayerFromDatabase().

Engine\Models\Vendor.cs

Removed the unused function “RemoveFromInventory”

Engine\Utilities\PlayerDataMapper.cs

Removed unused “ex” variable in catch statements

SuperAdventureConsole\Program.cs

Removed unused “args” parameter.

Manual refactoring changes

I also went through each of the classes, since this is a small program, and checked for unused (or commented-out) code and removed it.

Engine\Models\Player.cs

Removed commented-out line from CreatePlayerFromDatabase function.

Summary

There wasn’t much unused code, and this is a small program, so this step wasn’t difficult.

In a larger program, if you need to remove a large amount of unused code, do it in small steps. After removing a class (or a few functions/properties/etc.), rebuild the solution, run the tests (if there are any), and run the program. You may find the code you removed actually was needed.

If everything still works, commit these few changes to your source control, as a “checkpoint” save. Just like playing a computer game and you’re about to enter a new dungeon. If things don’t work out, you want to go back to a recent set of working code.