Refactoring Idea

As I was refactoring some of my code at work today, I found another example of refactoring that would come in handy: De-sugaring code segments that are syntactically sugared.

In my case, I had to support a changed business rule that required nullable DateTime objects instead of ValueType DateTime objects. So I tried to change

DateTime dtNull = ( /* my condition */ ) ? new DateTime() : DateTime.Today;

to

DateTime? dtNull = ( /* my condition */ ) ? null : DateTime.Today;

Of course, Visual Studio gives me a compiler error if I make this change because “there is no implicit converstion between <null> and ‘System.DateTime'”. However, the following does work:

DateTime? dtNull;
if ( /* my condition */ ) {
    dtNull = null; }
else {
    dtNull = DateTime.Today; }

It seems that refactoring something like this should be very easy to automate. Unfortunately, to my knowledge, Visual Studio 2005 is not as extensible in the area of refactoring as it is in the area of Code Snippets.

See Your Own (.NET) Reflection

Two posts in one week?! Ney, two posts in one night! This must be some kind of record!

I thought I’d mention a nice little .NET tool from Lutz Roeder, called the .NET Reflector. This tool is one of my personal favorites because it allows you to take any .NET assembly and view the source code directly in your language of choice, all thanks to the CIL. (If you are using .NET and don’t yet know what CIL is, you may want to look it up).

Continue reading

The Podcast Bug, Part II

iPod WheelBack in January, I posted on getting into the world of (listening to) Podcasts. I said I would discuss some good podcasts once I had sampled a few, and now I am… three months later…

.NET Rocks: This weekly Microsoft-oriented webcast can be a bit overly technical at times, but is a good listen for Microsoft software developers wanting to stay on top of the next big technology.

Continue reading

Snippy for your C# Code Snippets

For those of you working with Visual Studio 2005, you’ve no doubt discovered the awesome power of Code Snippets, as well as the ability to design your own Code Snippet templates. Unfortunately, for those of us developing in C#, Microsoft kind of forgot about us when they decided to create a code snippet editor tool.

Code Snippet example

After a bit of Googling, I came across Snippy, a tool for generating Code Snippets for C# developers. So far, I’ve used it for some fairly simple templates, and it seems to work pretty well. The documentation was a little less-than-useful however, and I ended up loading Microsoft’s code snippet files as examples to see how to build my own template.

The UI is basically laid out as the XML tags would be generated, but it is definitely a time-saver over writing straight XML – once you do get past the 5 – 10 minute learning curve.

WordPress, Site Updates

I updated my WordPress blog software from version 1.5.x to version 2.0.2 this week and I must say that I really do like the upgrade. There are a lot of new bells and whistles that have been added just to the Post-writing section alone. And the upgrading was a piece of cake, thanks to their excellent documentation page.

In other news, I’m continuing my work on a new design for the site. It’s not that I don’t like the default theme I chose for my blog (because I do), I just want to make it a little more personalized. Hopefully, I’ll have the design finalized this week and I’ll begin implementing it by the weekend.

Haven’t decided if I want to incorporate theRingworX into my blog title or not. Decisions, decisions…

Tips for Effective Unit Testing

I can see a lot of benefits for practicing TDD when developing software applications. But writing Unit Tests can be a lengthy process when done effectively, and it can be difficult justifying the time spent, especially to managers or clients.

So, here are a few tips I’ve learned from my own experience:

  • Do not test Getter/Setter properties. For the most part, getting and setting properties is a trivial matter. In the instances where complex logic is implemented in the property, you can usually still get away with not explicitly testing them. Or, test them via another unit test that verifies some business rules.
  • Remember good OO Design. If you are not using good OO design, your unit tests will be pretty difficult to write and maintain. Just as small changes in a highly-coupled system can break other parts of the system, the same can be said of your unit tests.
  • Do not test for the sake of testing. Although some may argue, I don’t find it necessary to write tests for every class in my project. Unit tests are intended to treat your classes or projects as a black box. The test gives an input, receive an output, and tests it to see if the expected value is equal to the actual value. Therefore, it is possible to write unit tests primarily for controller classes, and test the business classes implicitly.

If you know any other tips for writing effective unit tests, feel free to post a comment and share your experiences.