Home » Programming Best Practice » Treat Warnings As Errors

Treat Warnings As Errors

TreatWarningsAsErrorsI used to ignore warnings when I compiled my code.  Most of the time they never caused any problems and I was able to run my code.  But recently I’ve gotten pickier about my code.  One area I’ve gotten more picky about is compiler warnings.

Any code that I have direct control over now compiles cleanly.  No errors and no warnings.  This past week I found a perfect example of why.

Given the following code:

public class Class1
    public virtual int 
        PropertyOne { get; set; }

public class Class2 : Class1
    public int 
        PropertyOne { get; set; }

You will get the following compiler warning:

‘VirtualShadow.Class2.PropertyOne’ hides inherited member ‘VirtualShadow.Class1.PropertyOne’. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.

No big deal.  In fact, if you aren’t looking for it you won’t see it.

But here is the problem.

If you instantiate an object of Class2 and assign it to a variable of Class1 and then you assign the value 1 to PropertyOne using the variable of type Class1, if you tried to then access the same object from a variable of type Class2, PropertyOne will still be zero.  The default value for a property.

The default implementation is to treat Class2.PropertyOne as a shadow of Class1.PropertyOne, not as an override.  The warning message is telling you that it would prefer that you be explicit about what you really want the computer to do, which you have not done.

For this reason and others, I have all my projects set to treat warnings as errors in the compiler options.  It saves me from unexpected consequences like this one.


Other post in Programming Best Practice

Related Post

  • YAGNI – You Aren’t Going To Need ItYAGNI – You Aren’t Going To Need It One of the design principles in software development is to only write what you need today.  This has taken on the moniker of YAGNI (You Aren’t Going To Need It). The question is, […]
  • Avoiding Code ComplexityAvoiding Code Complexity A couple of weeks ago, I talked a bit about how we name things.  Specifically, I talked about the very bad habit of using the variables i, j, and k as variables in our for/next loops. A […]
  • DRY ProgrammingDRY Programming Today I thought I’d talk to you about the programming principle known as DRY.  As you may know, DRY stands for “Don’t Repeat Yourself” and it shows up in a lot more places than you might […]
  • How to Sabotage EstimatesHow to Sabotage Estimates Over the last week, I’ve been helping other programmers estimate the task they’ve been assigned and this has caused me to reflect on how I estimate software.  What works.  What doesn’t.  […]
  • Make Your Test Work For YouMake Your Test Work For You So far we’ve been talking about creating test as part of the development process.  If all you ever used those test for was to make the design of your systems better, you would already […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS. Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback