Home » blogs » Andy Brummer's blog

Programming style

Posted June 2nd, 2006 by Andy Brummer
| | |

I've been using Framework Design Guidelines for a couple of months now, and reading Brad Abrams blog for longer. It's a great book BTW. Not only does it go beyond the usual naming convention standards, it let's you know what to expect from the .net framework and how to write code that works well with it.

One of the suggestions and also one of my pet peeves has to do with returning collections. You should always return a collection even if it is empty and never return null. Null doesn't add any information to the caller and just forces them to write extra code which has no real meaning other then handling an edge case.

That's my rant for now.

Thanks

Andy Brummer's blog | login or register to post comments | printer friendly version

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Amen brother

On June 7th, 2006 Paul Bradshaw says:

That's right up there with "Don't throw exceptions for expected cases" such as, I don't know, Trying to load a business object by it's primary key, and it not being there. There's a case where throwing the exception gives you no more useful information than just returning null.

login or register to post comments

As long as that's the only reason.

On June 8th, 2006 Andy Brummer says:

What I think is worse is returning null when you should throw an exception, like when you can't connect to the database or there is a sql error. If you return null for those cases then null becomes a meaningless value, and you have drug yourself back to the world of HRESULTS.

At least developers here haven't been spooked by the exceptions are slow thing. I've worked with developers that refused to use exceptions because they read that they were slow, but thought nothing about performing a database operation once per loop.

login or register to post comments