No More Magic Strings! Presenting: @string.of

The Problem

How many times have you seen the following code snippets?

1. Checking method parameters

if (executeMethod == null)
{
   throw new ArgumentNullException("executeMethod");
}

2. Implementing a property in a WPF / SL view-model

public double Size
{
   get { return _size; }
   set
   {
       _size = value;
       RaisePropertyChanged("Size");
   }
}

The first time I had to wrote code like this I felt uneasy. Hardcoded strings are bad practice and should be rarely used.

Even worse, using a hardcoded string of an identifier is just a bug waiting to happen.

Consider what happens when you need to refactor your code and change the name of the Size property (second example) to something different like MaxSize.
The refactoring tools will not change the hardcoded string “Size” and now your WPF application stops notifying on property change the way it should!

These bugs are very difficult to spot. No compile time error, no runtime error. Nothing. The only way to spot this bug is by testing this specific functionality.

I’ve checked a small WPF application and found 158 (!) instances of these
almost-bugs.

The Solution

Are you familiar with the typeof operator?
Don’t you just loved it if there was a stringof operator?

Read more: Arik Poznanski's Blog

Posted via email from .NET Info