CodeIt.Right Rules Explained, Part 16

Today, we bring you another post in the CodeIt.Right Rules Explained series.? Up until this point, I’ve been chronicling these posts by their number in the series, but I realize that the numbering: is both academic and relatively easily inferred via the posting category.? Nevertheless, in spite of changing the approach to the title, I’ll recap the premise, as I always do.

CodeIt.Right?is an automated .NET code review tool.? That means that it automatically analyzes your code and applies rules to it.? In the posts in this series, I explain those rules in detail.

In all posts in this series, I start out by listing these rules of thumb for static analysis in the hopes that repetition makes the point.

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

I’ll also explain, as I always do, that I don’t use this phrasing to seem clever or because I can’t figure out the more succinct logical conclusion that these two statements imply: that you should always understand why the tool is suggesting a fix.

I do this because static analyzer warnings present you with a choice: address the warning or ignore it.? And, whichever path you choose, you should do so deliberately and for the right reasons.? Decide to ignore the warning because you think what you’re doing isn’t actually a problem.? Or decide to address the warning because you understand that what you’re doing is problematic and not because you’re programming by coincidence.? Always know what you’re doing.

And with that, let’s dive into today’s rules.

Enforce Option Strict

Explaining this rule completes a trifecta of sorts.? This is a VB-specific concern, and we’ve talked about its cousins “enforce option compare” and “enforce explicit” in the 13th post and 12th post of the series, respectively.? Like those two, this one will be something of a corner case.

Here’s how you trigger the warning.? In a VB project, go into the project properties.? Then navigate to the “Compile” tab (shown at the left) and turn the “Option strict” setting from “On” to “Off.”? Here’s what that looks like:

Once you do this and save, you’ve changed the project level property.? Now when you run CodeIt.Right’s analysis, you’ll see the warning message, “Enforce Option Strict.”

Why does CodeIt.Right not like this setting?? Well, in short, because it makes it easier for you to make mistakes with your code.

And that becomes easier because of what option strict actually does?(and what turning it off undoes).? Option strict prevents three things in your code:

1. Implicit narrowing conditions, such as converting a Long to an Integer.
2. Late binding, wherein you declare a variable as an object and then set it to a more specific type upon instantiation.
3. Implicit typing that results in an object type, such as Dim x = 5, when Option Infer is off.

So when you turn it off, these things are allowed, which makes it easier for you to make mistakes, such as forgetting that you’ve declared something as a Long and assigning it to an Integer or accidentally omitting a type specification.? Generally speaking, you want to make it harder, not easier for people to make simple errors.? Keeping option strict on does exactly that.? It forces rigorous, explicit use of the type system.

Fixing this warning is as easy as can be.? Just go back into the properties and turn option strict back on.

Avoid Non-Public Fields in ComVisible Value Types

Switching gears, let’s look at something that falls under the heading of interoperability.? CodeIt.Right warns you to avoid having non-public fields in value types that are “ComVisible.”? To unpack that, let’s look at an example.

[ComVisible(true)]
public struct Customer
{
    private string _name;
}

What we’ve got here is a simple struct (value type), and we’ve decorated it with the ComVisible() attribute, set to true.? And finally, we’ve added a private field to it.? This hits all of the conditions that trigger CodeIt.Right to issue a warning.

So what’s the problem?

The problem has to do with how COM clients deal with value types.? COM is an older standard than .NET, and you can encounter some peculiarities when making them inter-operate.? One of these peculiarities is that any instance field on a value type is visible to a COM client and not just ones labeled publicly visible in .NET.

So CodeIt.Right is giving you a heads up that you might be leaking data that you intend to encapsulate.? If you’re going to have value types that are COM-visible, make sure you’re only storing values in them that you’re comfortable having publicly visible.? Then make any fields publicly visible.

Custom Errors DefaultRedirect Should Be Specified in Web.Config

Let’s now look at something else relatively easy to convey with a snippet of code?XML in this case.? This is another rule about web.config which we’ve discussed relatively recently here.

In some ways, the web.config file is your project’s nerve center, so there’s a lot that can go wrong there as far as CodeIt.Right is concerned.? Luckily, your custom errors setting isn’t one of those out of the box.? This is because you haven’t added an entry for it yet, meaning you haven’t had the opportunity to do anything wrong.

So why would you fix what ain’t broke?? Well, because of what is affectionately known as the “yellow screen of death” in the ASP world.? Here’s what that looks like, and you’ve probably seen something like this before on a rinky-dink website.

This screen occurs when you haven’t implemented any sort of global error handling for your application.? Enter the custom errors element.? You use this to specify a graceful way of handling errors in your application.? In the tiny example here, you do that by routing users to a page called Error.aspx whenever an unhandled exception occurs.

<system.web>
  <customErrors mode="On" defaultRedirect="/Error.aspx" />
 </system.web>

But let’s say that you forget to specify a default redirect page, say, by doing this:

<system.web>
  <customErrors mode="On" />
 </system.web>

This triggers the warning in question.? CodeIt.Right notices that you’re intending to handle errors gracefully but actually failing because you’re not specifying a way to handle them.? So to correct this, either remove the entry or else fix it to do what it’s supposed to do.

Until Next Time

I always try to include some variety in these posts, and this one was no exception.? First up was a VB-specific, global project setting that it’s important to get right.? Next, we went old school and looked at something important to keep in mind when writing .NET code that interoperates with COM.? And, finally, we looked at the world of web development and proper setup of your web.config file.

Stay tuned for next time, which will include the relationship between async and out parameters, the assembly info file, and casing conventions.

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.