88 posts tagged with "programming"

My team often starts Tuesday morning status meetings with a round of win/learn/fun - a team-building exercise where each person gets to mention an exciting "win", something they learned in the last week, or just something fun. Several weeks ago someone brought up C# Extension Methods as a learn. I could see the potential, but I didn't immediately think of any practical examples.

Problem​

You have an ASP.Net web service/site that needs to access network resources, and IIS is running in a service account that you do not want to have access to those resources.

Solution​

Create a custom network account and setup a separate application pool. Microsoft article How To: Create a Service Account for an ASP.NET 2.0 Application outlines some pros/cons and gives a few alternatives, as well as giving the basic instructions. However, I found that these instructions had to be modified with inclusion of a few extra security rules. Steps:

Here's a really dumb scenario that will illustrate a point about the usefulness of the "red, green, refactor" approach to testing and coding. Here's the functionality - need to test whether or not a string has a value other than 1. Let's say I write a method before any tests:

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;
    }
});

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:

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();