CodeIt.Right Rules Explained, Part 12

This week, we bring you another post in the CodeIt.Right Rules Explained series.? In case this is new for you, with each post in the series, I take you through three CodeIt.Right?rules in detail.? CodeIt.Right is an automated code review tool, making use of static code analysis.

As I always do with these posts, I’ll start with two solid 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.

And, as I always do, I’ll explain that I don’t phrase it this way to play some sort of game.? You might wonder why I don’t just tell you to learn every suggested fix and call it a day.

Well, I phrase it this way to make it clear that you face a specific choice each and every time you encounter an analysis warning: fix it or ignore it.? And when you make that choice, you should make it for the right reasons.? “I don’t know what this means,” isn’t the right reason.? I also approach it this way because trying to learn?all?of the rules at once would prove extremely daunting.

So let’s dive deep into understanding another three rules today.

Don’t Hide Base Class Methods

Let’s start with an easy one to grok.? CodeIt.Right advises you not to hide base class methods.? Here’s an example of some code you could write that would run afoul of this warning.

public class Phone
{
    public void Ring()
    {
        Console.WriteLine("Generic ringtone.");
    } 
}

public class SmartPhone : Phone
{
    public void Ring()
    {
        Console.WriteLine("Custom, user-defined song.")
    }
}

This code defines a class, Phone, and another class, SmartPhone, that inherits from Phone.? Both classes have a Ring() method and both Ring() methods do something different.? None of that seems sinister, though, so what’s wrong?

To understand that, consider the following code.

public void LetsCallPeople()
{
    var smartPhone = new SmartPhone();
    smartPhone.Ring();
    (smartPhone as Phone).Ring();
}

Admittedly, this is a little weird, but bear with me.? This is the most compact way I can illustrate the problem.? This code instantiates a SmartPhone and invokes its Ring() method, resulting in “Custom, user-defined song” appearing on the console.? But in the next line, it casts the SmartPhone to its parent, Phone, and then invokes Ring(), resulting in “Generic ringtone” appearing on the console.

Confused a little?? You should be, and that’s the problem.

What I did above?looks?like inheritance, but it isn’t.? It isn’t because you haven’t used the virtual and override keywords in the parent and child class methods, respectively.? So now, when you give the child class a method with the same name as a method in the parent, you’re doing what’s known as “hiding” the parent method.? And that causes different behavior depending on whether the invoker holds a reference to an instance of the child or the parent.

CodeIt.Right isn’t the only one that doesn’t like this.? Hiding base class methods also violates a code analysis warning in Visual Studio?and triggers a compiler warning.? It is, in fact, bad news.

If you’re intending for an inheritance relationship with the methods, then make the parent class method virtual and have the child method override it.? Otherwise, you can invoke the CodeIt.Right auto-fix option of renaming the child method.

Avoid Setting the AutoPostBack Property to True

For this next rule, we’ll take a look in the ASP.NET category of CodeIt.Right rules.? Here we find a rule that advises against setting something called the AutoPostBack property to true.? What’s that?? Here’s an example in Web Forms markup.

<asp:DropDownList ID="pets" runat="server" AutoPostBack="true">
    <asp:ListItem>Dog</asp:ListItem>
    <asp:ListItem>Cat</asp:ListItem>
    <asp:ListItem>Bird</asp:ListItem>
    <asp:ListItem>Hamster</asp:ListItem>
</asp:DropDownList>

Here we have simple markup for a dropdown list of pets.? Also notice the AutoPostBack property in there and set to true.? This is the source of the warning.? So, what gives?? If it’s as easy as setting a Boolean property to true, why does that property exist in the first place?? And what does it do?

Simply put, this causes the control to trigger a postback?to the server each time the selected value of the dropdown list changes.? In other words, any given change results in a POST to the server.? Web forms accomplishes this by adding JavaScript to the page, which is the actual mechanism for triggering the postback.

That’s?probably?fine, but there are users out there who might opt to disable JavaScript.? Such a user is going to have a rough user experience, needing to explicitly trigger a post with something like a submit button, assuming one even exists on the page.? It’s entirely possible that your form might be unusable to someone disabling JavaScript.

You’ll have to evaluate for yourself whether that’s an issue for your user base or not.? But, by default, CodeIt.Right will make you aware of this issue.

Enforce Option Explicit

For the last violation, let’s talk Visual Basic.? We don’t cover that nearly as much as C#, so let’s give it some love today.? Option explicit is, well, explicitly a VB construct.

In VB, you can set an option for whether to require explicit declarations of variables or not.? It defaults to on, but you can, in fact, turn it off.? When off, the compiler will gamely use a variable you haven’t yet declared or typed, much as you might expect in a language without strict typing, like JavaSscript.? And here’s an example of the fun?that can create for you.

Dim someVar As Integer = 12
Console.WriteLine(somVear + 2)

You might run this code, fully expecting to see 14 print to the console.? You would then find yourself surprised when, instead, two prints to the console.? After squinting at the screen, running it five or six times to make sure, scratching your head, and taking some deep breaths, you’d figure it out.? “Aha!? I misspelled someVar by transposing two letters!”

When you turn off the explicit option, the compiler will let you do this.? Caveat emptor if you want to make use of implicit typing.

If you do this for the whole project, however, CodeIt.Right will give you a?warning.? You have to kind of go out of your way to do this, as shown here.

But if you choose to do this, you’ll hear about it.? And rightfully so.

Until Next Time

As always, I’ve tried to add some variety to the mix today.? I covered a general object-oriented design concern first.? Then I walked you through a specific concern related to Web Forms controls.? And finally, I looked at a VB-specific bit of functionality.

Join us next time for a look at three more rules for improving your .NET applications.

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.