CodeIt.Right Rules Explained, Part 14

Today, I’m doing another post in the?CodeIt.Right Rules Explained series.? For anyone who hasn’t seen one of these before, here’s briefly how it works.? CodeIt.Right is an automated .NET code review tool, and it has a lot of rules to help you.? In the posts in this series, I explain those rules in detail.

Whenever I post in this series, I start with my two rules of thumb for static analysis.

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

As always, I’ll explain that I don’t phrase it this way because I think I’m clever.? I could just say, “Figure out why the tool is suggesting this.”? But I specifically opt not to.

The reason I do this is that whenever the tool confronts you with a warning, you have a choice: address the warning or ignore it.? And in either case, you should make your choice for the right reasons.? Are you ignoring it because you’ve determined that the pros of having it outweigh the cons the tool is warning you about?? Or are you ignoring it because you don’t feel like dealing with it?? The same thing also applies on the side of implementing fixes.

So, that said, let’s look at today’s three rules.

PInvokes Should Not Be Visible

If you’re a .NET programmer these days, it’s entirely possible that you’ve never encountered PInvoke.? By and large, the code that you write is all what’s known as managed code.? This is code that will always execute within the .NET framework.

But you can also tap into what’s called unmanaged code; this lets you work around/outside of the framework.? There are a few reasons you might want to do this.? Some of them include:

• Calling into old libraries that predate .NET.
• Tapping into lower level OS functions.
• Invoking native libraries that don’t target the .NET framework (e.g., written in C++).

PInvoke (or sometimes called P/Invoke, and short for?Platform Invocation Services) is a strategy for letting you make calls from managed code to unmanaged code by letting you declare a .NET method signature of your own that matches the unmanaged method’s signature.? Here’s an example:

public class OldSchoolDiskAccess
{
    [DllImport("kernel32.dll", SetLastError = true)]
    public static extern bool DeleteFile(string fileName);
}

This code declares a “DeleteFile(string)” method corresponding to one that you would find in the kernel32.dll file.? You would then use the code from that DLL by calling OldSchoolDiskAccess.DeleteFile(string) from wherever you wanted in your codebase.

Oh, and, by the way, this code would also create the CodeIt.Right warning, “PInvokes should not be visible.”? The problem here is that I’ve declared the proxy method signature as public, making it externally visible.? Why does this matter?? Well, clients of the code I’m writing could invoke this, having no idea that they’re getting into unmanaged code.? Mark the invocation private instead, and consume it where you need it.

Set All Windows Forms Designer Settings Correctly

This one is a pretty deep cut.? It pertains to WinForms (Windows Forms), and we’re not seeing nearly as much Winforms development these days.

Like WinForms itself, this rule is a bit obscure?but it’s useful. Unlike most of the rules here, this rule actually has to do with your Visual Studio settings.? That might seem a little weird, but bear with me.

Here’s a Windows Form in designer mode.? Note the dots on it, which represent grid cells to help you align controls using the drag and drop paradigm of the designer.

These dots don’t show up on the form?they exist to serve as reference points.? You can configure them in Visual Studio to have different spacing and you can also configure whether they appear or not.? Now, you can also probably imagine that this will get weird in a hurry when different team members in your group have different settings for this.? That’s where this violation comes in.

Here’s the Visual Studio options screen allowing you to configure this.

And here’s where you can configure this rule in CodeIt.Right.

Now, you’ll notice that the settings in CodeIt.Right’s profile editor and the Visual Studio options match.? When they?don’t, that’s when CodeIt.Right generates a warning.? You can use this to ensure that the team is all using unified settings to design your forms.

Avoid the Page.DataBind Method

Last up, let’s consider a performance concern.? CodeIt.Right admonishes you to avoid the Page.DataBind() method.? Here’s the dead simplest example that I can think of where you’ll see the CodeIt.Right warning.

public partial class _Default : Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Page.DataBind();
    }
}

Seems pretty simple and innocuous, right?? So what gives?? Why is this method invocation a problem?

Well, to understand that, let’s zoom out a little and consider the ASP inheritance structure.? The Page instance that we’re referring to in that method is actually defined in the Control class, meaning that Page inherits from Control.? This is interesting for a couple of reasons.? First, pages in ASP are just a specific instance of control, and any given control is associated with a page.? So every control, pages included, implements the DataBind method.

DataBind in ASP simply handles binding the control in question to whatever data source is defined for it.? So, for instance, if you have a GridView, you could set its data source to be the result of some query and then invoke its DataBind method?to bind the control to it.? This works the same way for pages but with a wrinkle.? The Page-level DataBind method works by recursively invoking the DataBind() method of all controls on the page.

So if you want to run DataBind() for literally every control on the page (unlikely), then this model is fine.? But if you want to be even the slightest bit selective, then this is overkill.? And CodeIt.Right lets you know it.

Until Next Time

As always, I’ve tried to vary things up a little to keep it interesting.? Variety is the spice of life and all that.

Today, we looked at a rule that applies to invoking unmanaged code from your managed .NET application, a way to ensure consistency in your WinForms design, and a performance-related issue for ASP applications.? I’d definitely say that ticks the variety checkbox.

Tune in next time for part 15, when we’ll take a look at another three rules.

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.