What's wrong with this code? There are unnecessary lines. So? Why care about unnecessary lines? Because it shows that the programmer was not really thinking about what he was doing.

MyObject obj = someList.Find(delegate(MyObject test)
{
    if (test.Id.Equals(packageId))
    {
        return true;
    }
    else
    {
        return false;
    }
});

Problem​

you have a method that logs a message using the Microsoft Patterns & Practices Enterprise Library Logging Block, and you would like to write an automated unit test for it in NUnit (or Team System — solution is easily adapted). Logging to a flat file doesn't work; the file is still open when you try to read it to verify that the message has been logged. Logging to the database doesn't work; it seems the log isn't written to the database immediately. And so forth. Is there an in-memory way of reading the logged message?

The op-ed, Is My Marriage Gay? in the New York Times (5/11/09), describes the unusual state of affairs surrounding marriages where one partner has legally changed gender after the marriage was recognized by the state. The country is patchworked with statutes and laws that make such a marriage anywhere from fully recognized to partially tolerated to anathema. And this makes no sense to me, except in recognizing that people are afraid of what they do not know. Well, go hug a transgendered person today (in person or virtually if that's what it takes). Get to know her or him.

A few months after I first purchased it, I am still reading xUnit Test Patterns. Been reading a few pages every day - now on page 590 with a few hundred to go!

I have finally arrived at the point where the author describes the pattern Test Specific Subclass (TSS). This is a pattern we have used extensively in our testing at the office, so that we can access protected methods in our classes. However, we stumbled upon it on our own, well before reading anyone else's suggestions on how to apply it. That's the nature of patterns for you.

We just upgraded our servers to support .Net 3.x, so at last I'm able to start migrating some of my code. I haven't taken a close look at all the features available yet, but one that caught my eye and initially excited me is automatic properties. However, I had two conflicting reactions:

1. This is great, I don't have to create a private field and write getter/setter in a public Property anymore.
2. But then what's the point of not just creating a public field and using it directly?

Well, this article addresses a primary benefit: this facilitates refactoring. If, for instance, we find later on that we need something more advanced than a simple get or set statement, then we can add it without breaking the interface. I'm sold.

One of my team members sent in the following piece of code, which is clearly intended to update the OrderNumber field for all objects in a List<T> of objects that match a particular productId. I took one look at it and thought "you can't do that!". But then I let the automated test run to see what happens... lo and behold, it worked. And well it should, once I thought about it.

Coding Horror, almost two years back, christened a name for the principle variously known as "don't repeat yourself," "once and only once," etc.: Curly's Law. Excellent formulation of the principle. In sending this to my development team, I thought it would be useful to pull this from the abstract to the specific through a few questions:

Lately I've been working with my team to understand and utilize good automated unit testing strategies with NUnit. A code release I was inspecting revealed a couple of good points that seem worth expanding on: the importance of testing each layer, and the need to pay attention to code coverage. This is a rather facile treatment; for more in-depth reasoning and details, I recommend xUnit Test Patterns.

Something I was reading this weekend pointed out that leaving braces out of a one-line block can be dangerous. For instance, it is correct to code the following (and I do it all the time!)

if (someCondition)
    this.doSomething();

If our economy is in need of a financial bailout, then perhaps our society is in need of a nature bailout. I've often felt that lack of spirituality is one of the strongest elements holding society back from a greater advancement of the general weal. New evidence suggests that lack of contact with the natural world stunts individual focus, resolve, and calm — in other words, it interferes with our ability to approach the world constructively. I'm convinced there is a connection between these two notions, though I'm not ready to explore that connection just yet.