Apr 1

Why You Shouldn’t Build Warnings Into Your Interface

Category: Programming

Below the link, why I think you should never under any circumstances design a feature that needs a warning message by design.

The Overview

As it happens I recently wrote a custom language for one of our products. This brings up a lot of interesting topics including if anyone should write a custom language these days instead of a domain specific language or an XML variant. Anyway, as we extend this language a number of other developers have suggested we add warnings.

I have taken the position that we should never ever design a feature that includes a warning message. This seems pretty hard-line so I thought I’d discuss why in more depth.

What is a Warning?

It never hurts to clarify what you are talking about. A warning is a message generated by your language/product/interface/whatever that indicates the user has done something that while technically allowed may have an unexpected result.

Some Examples

So here are some things that generate warnings (at least in some compilers):The old C language = vs. ==.

/* in C*/
if(x = 4){
}

With C++ exception specifications (if you don’t know what they are take a look Using C++ Exceptions Effectively) I clearly throw an exception when the function has an empty specification list.

/* in c++*/
void blah() throws (){
    throw 1;
}

A C/C++ a switch without a default:

switch(x){
    case 1:
       break;
}

I would also add Turbo Tax audit check or the “are you really sure” buttons in any number of applications.

So Why Not?

Hopefully, put in this way the basic reason is obvious. If the language behaves in a way that is likely to be confusing: it’s a flaw in your language. Either make it an outright error or provide two separate and clearly delineated features.

For instance, Java doesn’t interpret integers as booleans, throwing undeclared exceptions is an error, and the switch statement should simply always require a default.

Similarly, Turbo Tax only does an audit check because tax forms are confusing and “are you really sure” buttons are often the result of putting the “delete everything” button right next to the “save files” button.

Even if that isn’t the case (I challenge you to come up with a good example of a warning that isn’t a result of poor design), warnings end up being pretty useless to the developer anyway.

Most coding guides indicate that code should compile without any warnings. The first reason for this is that if you allow warnings to remain in the code, it is difficult for the developer to notice new ones.

If you refactor code that has 20 warnings and you cause a new warning what is the likelihood that you will see it?

Second, if you write new code that has warnings it essentially implies the intent of that code is unclear to the compiler. What is true for the compiler turns out to be largely clear for the maintainer as well. If you write if(x=1){...} you may know what you meant but I probably don’t.

If you add warnings you are simply highlighting a failure in your design, not helping your future user.

You Mean C Shouldn’t Have any Warnings?

Let me be clear: C/C++ needs warnings. Hell it needs more warnings. The key point is that these languages are already out there. You can’t change the basic features no matter how broken they are so you add a warning (and preferably deprecate the problem feature).

The unfortunate result is that people have become so used to warnings that they build them into their interfaces by design. Just because language ‘X’ or GUI ‘Y’ did it that way doesn’t mean you have to. Often these decisions were made because of a lack of foresight or because of a resource constraint.

Times have changed, languages have evolved, and computers are orders of magnitude more powerful. Challenge questionable design assumptions and create your interface with the modern world in mind; Don’t build in flaws out of habit.

The Author

Michael Smit is a software engineer in Seattle, Washington who works for amazon

1 comment

Comments are closed.