Watch those names...

I was refactoring this code:

StreamDto dto = iStreamMgr.GetStream();
if( dto.IsNotNull() )
{
...
}

Resharper was underlining the StreamDto declaration telling me to use var. I told resharper to go ahead and make the switch and ended up with this:

var dto = iStreamMgr.GetStream();
if( dto.IsNotNull() )
{
...
}

In my view, this was a big mistake, not because of the refactoring but because it exposed a weakness in my variable naming. When the "StreamDto dto" syntax was there the reader could easily see what type dto was by looking at the declaration. After the refactoring this is hidden and can only be determined by "insider knowledge" or inference.

Recognizing this I immediately changed the code to read as follows:

var streamDto = iStreamMgr.GetStream();
if( streamDto.IsNotNull() )
{
...
}

This may seem a small point but the longer I code the more convinced I am that one of our great short comings as a profession is that we constantly "drop context." If you're going to code better oop code, you need better abstractions, when you have better abstractions, context becomes all important. This often explains why some of the most brilliant code is so hard to understand.

The great programmers include context naturally; for them it flows. Me, I have to work at it.