Source Control Check-ins

People I work with me are probably tired of me beating them up for not checking in code often enough.  I try to promote the idea that if it makes the product better or closer to completion, check it in.  It doesn’t have to perfect, or even testable to warrant a check-in.  Just don’t break the build or existing functionality.  With small check-ins, integration becomes less of an issue, and others can see what’s going on and where we’re heading.

Jeff Atwood does a good job of making the point here

Use of c# var – Lazy or Flexible?

A code review today raised concerns about the use of var such as:

var results = new List<LabResultSummary>();


as opposed to

List<LabResultSummary> results = new List<LabResultSummary>();


Specifically, the question was “Why is type inference needed or even useful in the below? I gotta say, it smells of a lazy developer to me. “

And then my response:

—————————————————————–

My first inclination to “var” was similar to yours, but I’ve converted.

1. For small methods (which all methods “should” be), what the variable is is obvious from how it’s instantiated (You can only use var when it’s instantiated in the same statement as it’s declaration)

2. It’s still strongly typed (it’s not a vb6 dim object/variant)

3. You can only use on private method variables, so no “leakage” of intent.

4. And damn, when I’m writing a lot of code that’s in flux, it’s saved me lots of work to just change the variable type. For example, refactor a method to return the interface instead of the concrete type. I don’t have to go and touch every single variable that ever called that function.

There’s probably others, but that’s off the top of my head. Again, when I first read about them, I got the “smell” too. But decided to give it a shot and have become a fan. Makes my coding agile

————————————————————

Thoughts?

Unit Test Presentation

So I did my presentation yesterday. The focus morphed a bit from the initial concept. It ended up focusing more on refactoring legacy code to make it testable. While the examples I gave still had some mocking in them, that was not the focus. I really tried to impress upon people the need for small, cohesive methods and classes. We discussed Test Specific Subclasses, Dependency Injection, and some design patterns. We also touched on some general unit test concepts. Overall I was happy with the material I was able to present within the hour time limit. If you were there, what did you think? Did it help or was it information overload?

#Region issues

Good points made by Jeff Atwood concerning issues with #Regions in the Visual Studio editor. I admit that when I first started doing .NET, I fell into the trap very easily. Now it’s just a pain. Pain to keep the organization straight, pain to read/scan the code. Just the other day I was having trouble searching for text, finally realized it was part of a collapsed section and therefore being ignored. Grrr..

Unit Test Presentation

Worked a good bit on my unit test presentation over the weekend. It’s amazing how little material can be covered in an hour. When I started this, I had all these ideas about what it could be, but reality set in pretty quick. Not just time constraints either. What initially seemed like simple refactorings got a lot more complicated once they go up on the screen.

On the positive side, PowerPoint is the first Office 2007 app that seems more intuitive than its predecessors. Most likely due to my lack of familiarity with its previous version.

Castle Windsor

Earlier today I managed to get sample code working that integrated Castle Windsor with ASP.NET MVC.  By creating a custom controller factory, I was able to delegate to Windsor to create the controller.  A side benefit of the custom factory is that there is no more “magic” that converts a call to “service” to the class “serviceController”.  Hopefully I’ll have some time to go further down this path to see if it really ends up helping some of our dependency issues, or if I’m just adding more problem points.  I expect the tough issue will be deciding which classes should go through Windsor and which should stay as they are.

Either way, I’m going to also give it a shot on my home RssReader project.  Since that’s in it’s early stages, should be interesting to see it evolve with Windsor integrated from the get go.

Project References

This issue keeps popping up in our environment, so figure I’d put out this quick tidbit:

When adding references to libraries that exist within the solution, you should make sure you add the reference via the Project tab, not the Browse tab.  This means you will have to have the target project loaded in the solution to add the reference.

If you don’t do this, command line builds will still be ok, but builds within the IDE can get all messed up due the the build order not being what it should be.  In general, you will get error messages indicating TypeA can not be converted to TypeA, which doesn’t make any sense.  What’s really happening is TypeA in the dll can not be converted to TypeA in the currently loaded project.

Once you fix the references, all should be good again.

Mocks

So, I’ve been tapped to do a presentation at work on using mocks for unit testing. Not a big deal really, I introduced some examples of using Rhino Mocks to do unit tests on our data layer code over a year ago. This led to a some interesting patterns in our code structure, combining command and template patterns, resulting in a single class for each query/save operation. Overall, I was very happy how it all turned out.

Now our focus is on testing the business layer. That also turned out to not be so bad since the business service allowed for some dependency injection.

But as I start getting closer to the presentation layer, things aren’t behaving so well. So I’m looking at refactoring in different ways:

1. Create test versions of classes that inherit the object under test. Let the test version override factory methods and have them return doubles/fakes/mocks at test time. My main concern is that the virtual methods will get abused in production code.

2. Create a more structured service locater factory, let it’s methods default to returning the types you’d expect in production, but allow other types to be registered for unit tests. Worried about issues with constructors/initialization logic here.

3. Use an Inversion of Control (IoC) container such as Windsor to manage dependencies. I haven’t played with this at all yet, but my gut feel is that we have way too many objects to define in a config file. Also worried about constructor/initialization logic. Obviously, I need to play with this to get a better feel for things.

In the end, I’m sure all of these are valid options, and will just have to see which tool to use in each situation.

I’ll try to get some samples written up soon to clarify the different options I’m considering

Back again

Giving the old blog another try. Intent here will be to mostly discuss software development topics, but I’m sure other stuff will creep in from time to time.