Is there a name for the not given/null/empty-problem?

Question

I work with code, where data is stored/exchanged in Hashtable/Dictionary/Associative-Array-like structures, like this

{
   'alpha': None,
   'bravo': '',
   # 'charlie' is not given
}

there is not much standartization, which field is 'given', and when given, if it may be given as None/Null/Nil or an empty string. As a result, the code is littered with checks like if hasattr(obj, 'alpha') and default fallbacks.

Is there a name or slang term for this kind of (imho) anti-pattern?

UPDATE:

it seems, currently there is no name, so i'd like to hear suggestions. Currently we have these:

• Incorporeal Horde (credits to psr)

Answer 1

I don't think there is such a name (I looked, but of course how can you find a lack of a name)?

I suggest the name "Incorporeal Horde", though I would apply it to the full collection of null or degenerate objects - zero size collections, null, undefined, nothing, None, NAN (arguably is a different kind of edge case), DBNull, void, empty string (arguably an empty collection special case), missing dictionary entries, etc.

And I wouldn't call it an anti-pattern, per se, but as an issue in software development, especially in the case where your programming environment requires you to write separate code for many of those cases.

Apologies for a fairly non informative answer, but I think it's the best that can be done. Plus, if the world adopts a name due to your question it could become a correct answer.

Answer 2

As far as I understand using Null Object pattern is quite a popular way to address issues like that. I've been using it myself, it really helped to avoid flooding code with dumb null-checks

in my codebase, these 'meanings' are ignored. Different parts of the application may all answer for the same Order: {'positions': None}, {'positions': []} or just {}

well for kind of problems like described above my label is inconsistency. Been using it for ages, never had problems communicating it to others. Highly recommended. I doubt that it categorizes as anti-pattern though, in all my communications agreed perception was that it's just a defect (bug) – gnat Aug 31 at 12:50

Answer 3

In F# this is provided through an Option Type (similarly to earlier languages in the same family). I have used the same concept in a C# project where I have a rule that I try to never return null from a function, but I return the Option<T> of that type of there's a possibility of a None value. That way the calling code knows that it has to deal with that possibility in the return value.

I would prefer to have non-nullable reference types, just like we now have nullable value types, but that's another story.

Answer 4

In JavaScript, this is referred to as undefined, which is a unique sentinel value, distinct from null.

You get undefined by either evaluating the global variable undefined, or a property of an object, that is not defined or by evaluating a statement, that doesn't return a value, such as calls to functions, that don't return anything, or a block or a variable declaration (although those two aren't valid expressions, so you will only encounter that in a JavaScript REPL).

When the undefined value is coerced to be an Object it becomes null, but it is not null.

Here's a little illustration:

var a = [1, 2, 3];//undefined
a[0];//1
a[4];//undefined

var o = { foo: "123" };//undefined
o.foo;//"123";
o.bar;//undefined

function bar() { return null; };//undefined
bar();//null
function foo() { /*just an empty block*/};//undefined
foo();//undefined

typeof undefined;//"undefined"
typeof null;//"object"
null == undefined;//true - that is because undefined is converted to an object for comparison and thus yields null
null === undefined;//false - because they are not the same

I think it is reasonable to call undefined values (in contrast to values defined to be null) undefined, if that is your question. Using a unique sentinel value to communicate the absence of a defined value is a workable solution for dynamic languages, although it is often poorly understood.