Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)
share|improve this question
4  
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
show 2 more comments

4 Answers 4

up vote 6 down vote accepted

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.

share|improve this 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
add comment

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

share|improve this answer
1  
thanks, but i am more interested in finding a name for 'issues like that', the solution is not the problem. –  keppla Aug 30 '11 at 15:27
    
I see. I'd upvote this question twice now that you clarified the intent. Meanwhile, until somebody suggests a better name, i'd tag issues like that as real life. I mean, uncertainty and unknown are part of real life aren't they? –  gnat Aug 30 '11 at 15:32
    
I would tag it 'real life', if we were not in control of the 'senders', but we are. So it's more like 'our fault' –  keppla Aug 31 '11 at 6:24
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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