The difference between ‘expected but not desired behavior’ and a software bug

bugdefectissue-trackingterminology

Recently I asked this question. As commented in the answer by someone who sounds like a numPy developer, this behavior is clearly not desired. The issue posted was closed stating that this is expected behavior but not a bug. Additionally there are plans to fix it.

What is the difference between a bug and behavior which is expected but not desired? Do those terms have precise and consistent definitions?

As a silly extreme, if a program always returns 3 when asked to compute 1+1, returning 3 is certainly expected behavior by the program since it has always worked that way, but it certainly isn't desired behavior, so is it a bug or not?

Recently I've been studying philosophy and this question has struck my interest.

Best Answer

It is known as a wart.

From a comment on the original post on Stack Overflow,

To be clear, this is not desired behavior, although there are good (historical) reasons for it. We (numpy devs) have preliminary plans to deprecate it in a future release, and provide easier to understand functionality that works as you might expect. See http://github.com/numpy/numpy/pull/6256 for more details. -- Stephan

Every design decision is a trade off somewhere. Make something simpler somewhere, and somewhere else something may become more complicated.

Consider this bit of JavaScript:

>>> '5' + 3 - 3
50
>>> '5' - 3 + 3
5

Is that a bug? No. Is it desired behavior... eh... I don't want to say people want it to work that way, but that's what you get with the 'this is how it was decided + works.'

Or in ruby that x?2:3 is a syntax error (it needs to be x ?2:3 - notice the space). Why? Because it was decided functions may end in a ? and so x?2:3 is ambiguous - a space between the variable and the ? part of the ternary expression resolves that.

Or in PhP the decision to mimic Perl's auto-increment feature on Strings but lacking the restriction on the pattern leads to:

$foo = "3d8";
echo "$foo\n";
$foo++;
echo "$foo\n";
$foo++;
echo "$foo\n";
$foo++;
echo "$foo\n";

(ideone)
printing out:

3d8
3d9
3e0
4

And without too much difficulty one could probably find examples of design warts in libraries and languages across the entire spectrum of software that were made that had unintended that had unintended and possibly undesired but nonetheless expected behavior.

There were indeed (debatably) good historical reasons the design decisions to make it work a certain way. And the code works that way - its not a bug, it is working exactly as intended. With the benefit of hindsight, maybe those decisions weren't good and lead to undesired behavior, but the code is working as intended - there isn't a bug there, its a wart.

While I have listed a few warts that I can quickly show and tickle, there are countless ones out there. I really don't need more examples. I would frankly be surprised if one were to find a language or library that doesn't contain a wart.

Related Topic