Archive for the ‘best practice’ Category.
28th February 2008, 11:45 pm
I often find code which have several nested conditionals like this:
public void FunctionWithoutGuardClauses(Person person)
{
if (person != null)
{
if (person.Phone != null)
{
person.Phone.Call();
}
else
{
throw new ArgumentNullException();
}
}
else
{
throw new ArgumentNullException();
}
}
According to Steve McConnell in Code Complete 2 it is just fine with regards to putting the most probable clause first. But it is also an anti-pattern in this case; arrow code. With even more nesting it gets worse, and it starts to get nightmarish to follow the possible execution paths.
Oh, and see how I blatantly disregard the Law of Demeter!
Introducing Guard Clauses
A guard clause is a conditional which constitutes our first line of defence in our methods. It can break control flow in an elegant matter, so the only thing left to follow is the valid execution path.
There is also nothing wrong with more than one return path in our methods, as long as it is as clean as it gets with guard clauses. Atwood seems to think so as well, so I’m really home safe here ;-p
So lets see how the above code can be refactored with guard clauses:
public void FunctionWithGuardClauses(Person person)
{
if (person == null || person.Phone == null)
throw new ArgumentNullException();
person.Phone.Call();
}
So what are you waiting for, get those guards up and tear those nested nightmares apart!
2nd December 2007, 11:21 pm
Recently, we have gotten a couple of “fresh out of school” employees, and here the other day we went through the code of one of our applications and explained how it was built (at least how was supposed to be or “do as I tell you, don’t do as I do”).
Our O/R-mapper returns a generic Collection<T> when it is asked for a list / collection of some objects, and is consistent in doing so. The question however, was why that wasn’t a List<T>.
I had to admit I hadn’t dug into the material properly, so the question kindof got left there in open air. My bad excuse was of course I had been mostly doing managment stuff lately, and so was my companion presenter as well.
So to make a not so long story short, I had to dig into the collections that is found in .NET, and I explain them to myself for later reference, beginning with the aforementioned Collection<T> and List<T>.
The difference
Just to sum it up, Collection<T> is made for extensibility and List<T> is made for performance. See this and this from the FxCop guys.
For a full blown explanation, a great reference is also found here.
Use List<T> for all your heavy lifting internally, and expose a Collection<T> in your public API.
11th July 2007, 10:30 pm
An absolute rule for your database insert scripts and stored procedures should be to qualify all field names.
An example could be the following schema:
Where you would have a script saying:
INSERT INTO FAMILY VALUES (‘Bob’,‘Dolly’,‘Bill’)
Then, you could see the disaster inserting a new field named Girlfriend in between You and your Mom (in more than one way :-)).
Then you have a schema like this:
Suddenly after your next insert your Girlfriend is your Mom, and your Dad is your Mom!
Well, the one solution to rectify this mess is of course guiding your values into the correct fields like this:
INSERT INTO FAMILY (You,Girlfriend,Mom,Dad)
VALUES (‘Bob’,‘Julia’,‘Dolly’,‘Bill’)
The rationale is then as follows:
- This will assure that if you have changed the schema ie. moved or inserted new fields, the script will not fail or most importantly it will not insert data in the wrong fields.
- It will fail if you have removed or replaced fields which assures that you will not get corrupted data from these changes either.
