CodeIt.Right Rules Explained, Part 10

Like any good habit, I’ve settled into a cadence with the CodeIt.Right Rules Explained posts.? They’re coming about once per month or so, and each one offers a deep dive into three of CodeIt.Right’s?rules.? As always, I’ll start by citing my two personal rules about static analysis, along with a brief explanation.

• Never implement a suggested fix without knowing what makes it a fix.
• Never ignore a suggested fix without understanding what makes it a fix.

This isn’t a rhetorical game.? I could condense the statements and say ?learn the reasoning behind all suggested fixes.? ?But I say it the way that I do to call your attention to a decision that you face when it comes to static analysis warnings. ?Every time you encounter a warning, you must either choose to ignore the feedback or to address it. ?And regardless of which you chose, you should really understand the logic behind the suggestion. ?Otherwise, how can you possibly make the right call?

In that spirit, I?m going to offer up explanations for yet another three?CodeIt.Right?rules today.

Assemblies should have valid strong names

I’ll start with one you’ve probably seen before in your travels at some point or another.? This warning tells you that assemblies should have valid strong names.? Off the cuff, this sounds like some weird generic platitude, like someone advising you to name your child after a Viking.

But in reality, this is advising you to do something specific and significant.? This CodeIt.Right rule echoes a Microsoft guideline, and it has to do with identity for your assemblies (DLLs and EXEs).

Going into exhaustive detail about strong naming would be beyond the scope of this post.? You can read in significantly more detail, if you’d like to learn more.? For our purposes here, though, understand that strong naming of an assembly conceptually amounts to creating a unique identifier for it.? Creating a strong name involves it containing a few things:

• The actual text name you give the assembly.
• Its version.
• Any culture information.
• A digital signature and a public key.

Why do this?? Well, this helps in a variety of ways.? It lets you register the assembly in the global assembly cache (the GAC), and it prevents general collisions resulting from different versions of your assembly.? It also lets the .NET runtime detect whether someone has tampered with the assembly, though you shouldn’t specifically rely on strong naming for security.

So when you see this violation from CodeIt.Right, you’re seeing a warning that you’re not making your assemblies uniquely identifiable.? It means you might not be completely thinking through what will happen to your code in deployed environments.? Luckily, CodeIt.Right not only flags the violation?but also lets you fix it with a click.? This saves you from the nitty-gritty details of the signing, if that doesn’t interest you (though you should learn this at some point).

Enable treat compiler warnings as error

Strong naming is a fairly specific concern, in the sense that it involves technical details about a naming scheme for assemblies.? This next warning is, in some ways, its polar opposite.? Treating warnings as errors is both a highly philosophical and extremely basic concept.

In case you didn’t know, you can ask the compiler to treat warnings as errors.? In other words, compiling the code fails not just on errors but also on compiler warnings.? This is actually a fairly universal concept and not unique to .NET.? But if you want to see the setting (disabled by default) in Visual Studio, here’s how you enable it.

By default, you won’t build .NET projects with that that option enabled.? You have to actually go into the build settings and opt in for this to work.? CodeIt.Right follows suit, with a similar default setting.? You have to opt in for it to flag this.

Why would you want this?? Personally, I like this option a lot.? Just as I don’t want compiler errors, I also don’t want warnings.? I keep my own projects to a zero-warning policy, and treating warnings as errors offers a handy commitment device for that.? Similarly, CodeIt.Right’s option offers me a handy way to see if I’ve forgotten to turn this on.

Your mileage may vary, but this is a handy way to check yourself against letting compiler warnings pile up.

Remove unused locals

So far, we’ve looked at a couple of assembly-level settings.? Let’s now get back to the granularity of source code, where the lion’s share of warnings exist.? CodeIt.Right advises you to “remove unused locals” and shows you a warning when you don’t comply.? What does this mean?

Let’s take a look at an example.

public int Add(int x, int y)
{
    int someVariable = 5;
    return x + y;
}

If you put on your code archaeology hat, you can probably imagine what happened.? At some point, somebody had some grand plans for someVariable, but those never materialized.? The method simply doesn’t make any use of it whatsoever.? And because of that, CodeIt.Right flags it with “remove unused locals,” indicating that you can just delete someVariable with no ill effects.

Note that it doesn’t matter that you initialize it to something.? You never use it anywhere.? In effect, this makes it dead code,?an insidious code smell.? Dead code sits uselessly in your codebase, confusing maintenance programmers, taking up space, and contributing nothing.? It accretes over time creating lots of cruft and the feel of a legacy codebase.? You should ruthlessly eliminate dead code.

As with the flag about treating compiler warnings as errors, the remove unused local rule comes deselected out of the box.? But in this case, I highly recommend that you enable it.? You want to catch dead code as quickly as possible.? The longer it sits there after becoming unused, the less confident everyone feels removing it.? Much better to get an early heads up.

One final thing to bear in mind with dead code finders (“remove unused X”) is that these can be expensive in terms of analysis time.? In large codebases, you’ll probably want to make a separate analysis profile for enabling this.

Until Next Time

As always, I’ve tried to offer a nice mix of issues.? Today, I started with “assemblies should have valid strong names,” which falls under the design category and ensures that you create a means of uniquely identifying your assemblies.? From there, I looked at “the enforce treat compiler warnings as errors” option, falling under the general category.? This helps you avoid metaphorical broken windows in the warnings list for your assembly.? And finally, I looked at an issue filed under performance, but it also has a?significant effect on the maintainability of your codebase: removing unused local variables.

Join me next time when I’ll walk through another three ways that you can improve your .NET codebases.

Learn more how CodeIt.Right can help you automate code reviews and improve the quality of your code.

About the author

Erik Dietrich

Website

I am Erik Dietrich, founder of DaedTech LLC, programmer, architect, IT management consultant, author, and technologist.

This author does not have any more posts.