I don't want to be a wet blanket, but someone's got to put a stop to the IoC love fest going on out there.  An Inversion of Control (IoC) container , for those of you were aren't yet familiar, allows you to retrieve instances of objects at runtime.  A relatively common solution to a common problem. In the .NET world there is no lack of choices of IoC containers:

• Castle's Winsdor/MicroKernel
• StructureMap
• Spring.NET
• AutoFac
• Ninject
• Unity
• Funq

(I won't go fully into IoC, but If you'd like more resource you can read Martin Fowler's article on the subject or post specific questions in the comments or contact me through.  Read on, there is value here in this post for you.)

Let me state clearly now, IoC containers are a means to an end and NOT a feature of your application. The goal is to have loosely coupled applications, IoC containers help get you there, but you can absolutely have a loosely coupled application without an IoC container (see the Gang of Four creational patterns).

Occasionally I'll hear some comment about IoC and how great a certain container is or how an application would be so much better if another, sexier, container was used.  Here are some recent tweets that illustrate:

• Man i love #StructureMap, always finding new things i can do, and have fun doing them
• really need to look at structuremap, but we''ve invested a lot into castle with our own facilities/resolvers/etc
• Ninject is da bomb!
• Switched from Windsor MicroKernel to Ninject in 10KLOC project in < 1 hour by creating a little proxy. Now to complete the conversion.
• It is a talk on Castle Windsor so i guess Ninject will not do.
• Can't imagine why somebody would use Ninject beside the fact that it's PURE AND UTTER AWESOME. Yeah! Ninject FTW.

Some of the statements above are probably innocuous, but some rub me slightly the wrong way.  Specifically the two comments above about switching from one container to another. There are probably times when the choice of one container over another makes sense, but I would bet that these scenarios are the exception and not the rule.

Choosing one container over another won't make your application a success, the architecture, or lack there of, will have far more of a say on your application than will your container choice. As yoda might say, "The container you choose does not a good app make".

I understand floating point numbers can be somewhat imprecise but I'm a bit bothered today when I see the following evaluates to false:

   1: float f = .16f;

   2: double d = .16d;

   3:  

   4: Assert.That(f, Is.EqualTo(d))

Annoyingly I wanted to see what the two values are:

   1: Console.WriteLine((double)f)

   2: Console.WriteLine(d);

produces the following respectively:

.159999996423721

.16

What bothers me about this, and I'm hoping someone can eloquently explain this, the MSDN docs say this should be implicitly converted.  From the MSDN doc article on implicit numeric conversions:

• From float to double.

Float is 32-bit and double is 64-bit, so why can't the float fit nicely inside the address space for the double?

Hell, if you're not going to respect the integrity of the number what's the point of the implicit conversion?

This past weekend I attended the Continuous Improvement in Software Development Conference in Austin, Texas.  This conference brought together many brilliant minds in the .NET community for the expressed purpose of continuous improvement.  The conference was very good, but some of the best chances for learning happened outside the conference sessions at dinner or sitting around a table at the hotel bar.  One such discussion seemed to point out one problem we have in our community, minutiae.

I will preface the remainder of this post by saying I tend to be a purist at times and must always remind myself what the ultimate goal is.  Acknowledging my tunnel vision, sometimes purists, can miss the point if we're not careful.  One evening a few of us got on the discussion of test-driven development.  Someone at the table used the phrase test-first development in the conversation.  That person was quickly halted by others at the table because the terms, in their opinion are quite different and should not be used interchangeably.  If I were to ask you define both, could you adequately define the difference?  Should you be able to?  Does it really matter?

I would say that for the development community out there that the differences, if in fact they do exist, don't matter.  A quick and informal poll revealed that 8 of 10 developers I know aren't unit testing at all.  I readily admit that my sampling is probably an inaccurate representation of the total developer population.  I don't think though that my sample poll is off by an enormous amount.  Think of the developers you know; are they testing at all?  I'm not talking TDD, but plain old unit tests?  Chances are good that you know a few that aren't testing at all.  Are they served by the bantering back and forth about differences between TDD and TFD?  Absolutely not.

The important thing to remember is that fundamentally the TDD and the TFD practitioner believe the same thing, that is, you need to be testing your code. They may disagree about small things, but those small things should take a back seat to the fundamentals.  We don't have to look far to see another example of this type of behavior.  Think of two Christian denominations, both of which are trying to convert nonbelievers to Christianity, bickering among themselves about whether children should be baptized or not.  The debate becomes so ardent, that neither camp accomplishes their original goal or converting nonbelievers because they're too focused on each other.  I fear the same outcome will befall those of us preaching testing.  We get so religious about the non-essential aspects of testing that we miss the people we intended to target, the people who aren't testing their code at all.

I think we could all take a page from St. Augustine who had it right over 1600 years ago: "In essentials, unity; in non-essentials, liberty; in all things, charity."

There's a lot of posts and chatter about testing, TDD, and a number of other topics on this blog, the larger devlicio.us site, and the .NET community in general.  Before all that, it should go without saying, but it must be said; there is a pre-requisite to testing, care about your code.

You have probably come across some code in your career that is less than ideal.  Maybe you've even submitted something to the Daily WTF. I'm currently combing some old code trying pull out some main concepts.  As I'm going through the code I'm seeing some things that really are quite alarming.  I'm not talking about differences in what I would do in terms in architecture, implementation, or even language choice.  I'm talking about blatant code rot, code that no one has cared for.

Some stats for the current file I'm in:

• Lines in file: 1820.  This is the mildest offense, while I don't endorse a class/file that large I can live with it.
• Classes defined in the file: 19.  I find this a "little" excessive, Even if you don't subscribe to the "one class per file" rule, 19 is a bit much don't you think?
• Example Method: 697 lines.  That number isn't entirely accurate as 395 of the lines are commented out.  I understand the scenario that probably led to this, in fact I'll admit to doing it.  You comment out some code as a fail-safe in case the new implementation doesn't work.  The problem here is that the code does work (and I use that term loosely).  The developer never cleaned up after themselves and their trial code.  This makes absolutely no sense when you have source control in place.

Here's a method I came across today:

   1: Public Overrides Function ToString() As String

   2:     If IsNothing(_fields) Then

   3:         Return ""

   4:     End If

   5:  

   6:     Dim r2 As String

   7:     Dim retVal As StringBuilder = New StringBuilder("", _fields.Length * 2) 'make room for 1 char and 1 delimeter for each field

   8:     For Each f As Field In _fields

   9:         r2 = r2 & f.Prefix & f.Value & f.Postfix & ConfigurationSettings.AppSettings("ControllerFieldDelimeter")

  10:         retVal.Append(f.Prefix).Append(f.Value).Append(f.Postfix).Append(ConfigurationSettings.AppSettings("ControllerFieldDelimeter"))

  11:     Next

  12:  

  13:     r2 = r2 & "<EOT>"

  14:     retVal.Append("<EOT>")

  15:  

  16:     'Return retVal

  17:     Return retVal.ToString

  18: End Function

The first thing I noticed was the string concatenation in line 9.  The problem is the "_fields" (the collection over which this code is iterating) can be large.  So concatenation isn't the best choice.  While clearly not optimal, let's let that slide for a moment.  The very next line, line 10, there is some appending of seemingly the same data.  In the end r2, the concatenated value which was so expensive to generate, is never returned or used elsewhere.  All of those extra, wasteful concatenation calls are spent on worthless code.  The developer(s) who worked with this over time simply never cleaned up after themselves or cared for the code.

I'm amazed that code like what I'm looking at is found in code bases.  I probably shouldn't be surprised but I am.  Today I was posting my reactions on Twitter and a friend Rhys Campbell commented:

"395 of them are commented out".. delete them! do it! You know you want/need to

I think Rhys is right, I will fix the code as I see it.  The codebase is being phased out but that doesn't mean it shouldn't be cared for.  If I am caring for code that is going to be obsolete and replaced soon, how much more important do you suppose is it to care for your current code?  If any of the above sounded like your code, get with it, clean up and care for your code.