The Daily WTF: Curious Perversions in Information Technology

2011-09-05 Reply Admin

Jeremy Foster:
http://msdn.microsoft.com/en-us/library/system.string.isnullorempty.aspx LOL standard classes?

Err .. quit citing microsoft when we talk about programming, it's off-topic.

Like MySQL when we talk dba stuff .. off-topic.

2011-09-06 Reply Admin

hoodaticus:
Agreed! They're "good". But there's a non-zero opportunity cost in doing it, so blindly doing it everywhere is dumb. But even then, doing it all the time is not a WTF, it's just... dumb, as shown below:
void foo(MyC

Addendum (2011-08-31 17:48): void foo(MyClass a) { if (a == null) throw new Blah(); a.Method(); }

Useless under all circumstances.

You've been spouting off for several pages here, and all you've been showing is ignorance and pigheadedness. Here's some facts for you to think about for a bit.

Nowhere in this WTF or even in the comments did anyone suggest you "blindly" check all arguments.
There is a HUGE difference between checking for and throwing ArgumentNullException and letting the code "naturally" throw a NullReferenceException: namely they are different exception types. .NET programmers expect ArgumentExceptions, making the former the correct thing to do.
Your trivial example is based on a specific implementation of foo(). When that implementation changes, what are you going to do?
There's a world of difference between these choices in modern day .NET languages, thanks to Contracts. See, the parameter checking is called a Precondition, and Preconditions follow contract inheritance rules (something which causing a NullReferenceException does not), provide documentation, and allow the compiler to do static analysis.

The reasons for coding as the "rockstar" in this story did are vast, while the only reason you've given (it may cause performance problems) is highly questionable and a certain famous quote comes to mind.

Go learn about DbC (Design by Contract), then come back and try to argue again, because so far your arguments have been more than weak.

2011-09-08 Reply Admin

pedantic:
bits:
I minus well not comment on the grammer - it's a mute point.
moot

http://en.wikipedia.org/wiki/Sarcasm

2011-09-14 Reply Admin

DonaldK:
Get off your high horse. It's very readable

Do you say "if it's true that looks like rain, then I carry an umbrella"? Or do you say "If it looks like rain, then I carry an umbrella"?

Readability is fine, but developers who do not understand that they can write

b = f();

instead of

if (f() != true)
   b = false;
else b = true;

have deeper issues to say the least.

As long as debuggers didn't allow conditional breakpoints I was willing to accept the second form.

2011-09-16 Reply Admin

ObiWayneKenobi:
That's the NULL OBJECT pattern that I'm familiar with. Your calling code never has to know that it's dealing with a null entity, just any operation is basically stubbed out.

First I'm not convinced that you can have a null behaviour for every conceivable operation. Fine, Employee::dateOfBirth() could return a Null instance of Date.

But there are still situations where you must know whether you're dealing with a Null instance:

If Employee::salary() returns 0, and you want to know the lowest pay in the company, you must either know that Null.salary() returns 0, or check Employee::isNullEmployee(); otherwise the result will not reflect the real world.

When calculating the average pay, you will need to know how many real employees there are. So you have to walk through the collection and again check isNullEmployee().

Note that just counting instances of Employee in a collection does not call a method of Employee, so there you cannot "stub out" anything or change behaviour by polymorphism---unless you add Employee::howMany() that returns 0 and 1 for Null and non-Null... now you only need to convince Container.count() to add up howMany() instead of relying on its own count_ variable.

2011-09-24 Reply Admin

For me, the decision of how much parameter checking to do is largely decided by scope. Private methods rarely require any, internal methods may need some, and public methods should always sanitise. That's just my general rule of thumb, subject to context.

Given that checking parameters for null is frequently required, I wonder if there's a case for some syntactic sugar on method declarations:

public void DoSomething(object nullsAreFine, notnull object nullsWouldBeDumb)
{
  // blah
}

I wasn't aware of Code Contracts, but they sound cool.

2011-10-03 Reply Admin

The real WTF is the amount of typographical, grammar, syntax, and lexicographical errors of both the users and administrators of this site, and the lack or a design principle that spans browser settings - such as text zoom - that plague this site. The "sense" in this article is what pushed me to finally comment about how piss-poor the standards for a site about quality assurance really are.

The Rockstar's Guard

Leave a comment on “The Rockstar's Guard”