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?


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

  • Incorporeal Horde (credits to psr)

closed as primarily opinion-based by gnat, user40980, user22815, GlenH7, Dan Pichelman Sep 30 '14 at 16:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    I wouldn't call it an anti-pattern. In the real world, there are situations when something is missing, and situations when not. If a default values makes sense, okay, but what if it really is null/non-existent? Some people don't have a middle name, for example. How would you represent that? That's why I believe it's more of a search for a better programming model for this kind of scenarios. Like the null object pattern, the maybe monad, or whatever else exists out there. – Ionuț G. Stan Aug 30 '11 at 15:32
  • Note that an empty string is a perfectly valid member of the set of all strings and is quite different from not having a string. It's like the difference between the 2 sentences: "I have 0 dollars." and "I won't tell you how many dollars I have." – Ingo Aug 30 '11 at 16:08
  • Python has a default dictionary which allows you to avoid these checks. Haskell has monads which solve all problems of the humanity. – Job Aug 30 '11 at 16:25
  • @Ionut: yes, there are situations, where 'something missing' is ok, but in my case, i think, it's more the case that one preferres to make 100 receivers tolerant for all possible bullshit than to make 1 or 2 senders obey to a format. The middle name (or generally every part of an address) is imho a classic case where '' is perfectly fine. – keppla Aug 31 '11 at 6:17
  • @Ingo: yes, but the problem is, that in my codebase, these 'meanings' are ignored. Different parts of the application may all answer for the same Order: {'positions': None}, {'positions': []} or just {}. – keppla Aug 31 '11 at 6:20

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.

  • I love "Incorporeal Horde". – Sean McMillan Aug 30 '11 at 20:09
  • Sounds like 'Magic the Gathering'. I Like it. +1. – keppla Aug 31 '11 at 6:23

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.


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

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

function bar() { return null; };//undefined
function foo() { /*just an empty block*/};//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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.