Author Archive

Recommend Visual Studio Test Project Organization

July 15, 2012 Leave a comment

I have to admit that I follow many SOLID principals for the sake of being able to test a project. However, for the most part, I rarely have a Unit Test suite. It’s kind of a puzzle as to why I don’t practice a more disciplined approach to Test First development.

In 2009, I decided to learn how to use the Unit Testing Framework NUnit. That journey opened a new window on how programming can be done. I have not worked in a shop that values Unit Test, so, I have often felt that I was “wasting” time.

Flash forward, 2012. Many of the patterns and practices have found a home in my toolbox, but, not Test First. I’ve started to seek out how others are doing this. Currently, I am subscribed to Pluralsight and have been watching the “Test First Development I & II” classes.

Below is the project structure that I am going to try and start using for my project setups:



Saying No to Nulls?

May 5, 2010 Leave a comment

Have you ever finished working on a method and noticed the amount of code you wrote just to make sure that your code was safe from some object reference that could be null?

John Sonmez asked that very same question over at Elegant Code.

    The more elegant solution is to focus on never passing null.  By doing this you will end up writing less code and avoid decisions about how to handle null inside of a method that doesn’t have enough context to decide what to do.

    The context of his statement lies within the code that you, or your company owns (develops).

Robert Martin in his book “Clean Code” states that returning nulls is just as bad:

When we return null, we are essentially creating work for ourselves and foisting problems upon our callers. All it takes is one missing null check to send an application spinning out of control.

Neither author is stating some new revolutionary call to never check for nulls – rather, as far as long as it is in Your control, do not pass or return a null object.

Jon provides the following suggestions for initializing objects:

  • Initialize your variables when you declare them.
  • Use the Builder Pattern.
  • Use properties to provide default patterns.
  • Make your objects immutable

Robert suggest that throwing a null exception or returning a special case object as options. And, if you are working with a third party API where the methods return null, you can always wrap or adapt the third party’s API so that you have more control with it’s interaction with your code.

Categories: Uncategorized

Misapplication of Something You Have Learned

April 25, 2010 Leave a comment

I think one of the hazards of learning something new is when you try to apply it to a particular problem. We’ve all been there.

Here southeastern Virginia, it is springtime. After a particularly cold and snowier than usual winter, the smell of fresh cut grass once again is in the air. A few weeks ago, I pulled my lawnmower out for the “first cut” of the season. It wouldn’t start. A friend of mine came over and showed me the problem: I had not drained the fuel from the last time I used the machine and now the carburetor was gummed up. He taught me how to clean it and soon we had the machine running.

Flash forward two weeks. Nearly the same scenario. I pulled the starter rope, and nothing happened. I looked at the spark plug, put a little gas in the spark plug hole which helped a little. But still, the mower would not start. I decided to pull the carburetor off again to clean it, which, still looked just as good as the last time. After reassembling, it still did not start.

Running through the possibilities in my head, it dawned on me that I had never checked the gas tank.

I had this new knowledge, I came across a problem and decided that this new knowledge would be applicable. It was not.

This applies to programming as well. I am currently trying to learn the GOF patterns. But, taking a lesson from the lawnmower, I am ensuring that I know the intent of the application.

Categories: Learning