Now, when you build the solution, you should see an “Error List” tab that displays any code that breaks a rule in your ruleset. Click on the “Run this rule set:” combobox, select “”, and select the ruleset file you created. Check “Enable Code Analysis on Build”, to have our rules checked every time we build the project. On the Properties screen, select “Code Analysis”. Right-click on the Engine project, in the Solution Explorer, and select “Properties”. Check all the rules you see listed for them. In the search box (upper-right of the tab) search for the following terms (without the quotes). As we clean the code, we can add more rules to check for. There are many rules we don’t care about right now – and some we probably won’t ever care about. To find unused members with a Code Analysis Ruleset, from the Visual Studio menu select File -> New -> File… -> General -> Code Analysis Rule Set. We just can’t find them through Visual Studio rulesets. So, we can safely eliminate unused public members in this program. With this program, the only projects using public classes are other projects inside the same solution. This could be true if you’re publishing them as an API through a web service or releasing your code as a library. This is because the code analyzer assumes public members might be used by other programs. Unfortunately, you can only detect unused private members. This is where you define the code issues you want to know about. In Visual Studio, you can create a custom “ruleset”. Here are two ways to find unused classes, properties, and functions. Common things that are missed are properties in XAML and parameterless constructors used for deserialization.
Sometimes, they say something isn’t used when it actually is used.
NOTE: The code analysis tools below aren’t perfect. 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. The next step I want to do is remove any unused classes, properties, and functions.
0 kommentar(er)
