There's very little that depresses me more professionally than coders who never try to improve how they do things. These are the kinds of people who've been writing unmaintainable 500 line switch statements for the last decade and resist all attempts to show them a better way. This topic is worth a rant in it's own right, this post is on how I try to avoid this fate by identifying development practices I have that I need to improve or replace.
 
I like .NET resources. They make it relatively easy to store common strings and such in a manner than allows for internationalisation. Not that I generally build applications that require this, but it does provide a handy mechanism to manage the things centrally. Of course it can be abused, which is the example I'm going to use today.
 
Another thing I like are unit tests. I like to have more unit test code than production code (up to a point, of course). I also like messages in Asserts to give some context as to what the error is. This means a lot of strings. On a number of projects I've worked on I stored these strings in a resource file in the unit test assembly. This allowed sharing of the messages between unit tests and the unit tests all ran. Managing the resource file was mildly annoying, but it didn't add measurably to development effort.
 
It was while editing a resource file to include yet another assert failure message that I stopped to consider if this approach was actually useful. After some consideration I've decided it's not, and I don't do it anymore. This is because:
  • Unit tests don't need to be internationalised (I accept you may have a corner case where they do, but this is atypical in my experience).
  • Typically I end up with the same strings being used in many unit tests. These strings are generic and don't really add value.
  • Using a custom string in each case allows more precise specification of the error.
  • Unit tests tend to require a lot of strings relative to production code, and therefore the overhead of maintaining the resource file is higher.
  • Error strings are more readable when going through the test code.
  • Consistency between error messages in unit tests is generally unimportant.
I haven't gone back and ripped out all the resource usage in existing tests as there's no value in doing so.