Jeremy’s post “Don’t Check In Spike Code” reminds of something I’ve advocated for years: dedicate a place in your source control repository where each developer can check in their “experimental” code. The rule of thumb is to throw away code you write for a spike, but all code can be valuable, even if it isn’t production worthy. Here are the kinds of things I’ve checked into “experiments/sallen” over the years: Code to isolate and reproduce compiler, framework, and library bugs. Code written to learn a new technology, platform, or library. Code that I almost threw away because...

There is a lot of humor in the Bad Variable Names entry on the c2 wiki. I like this confession from Alex: The worst of which was my counter variable names. I now use i, j, k, and so on for local counts and things like activeRowCount for the more descriptive names. Before, in the early years mind you, it shames me to say, I would name my counters things like Dracula, Chocula*, MonteChristo. They are all counts after all. I apologize for my intial variable naming conventions and shall go beat my face now as punishment. (*If...

Once you know about the magic of Expression<T>, it’s hard not to make use of it. Or perhaps, abuse it. Here is an excerpt of a class I wrote that uses Expression<T> as a reflection helper. public class PropertySpecifier<T> { public PropertySpecifier( Expression<Func<T, object>> expression) { _expression = (expression.Body) as MemberExpression; if (_expression == null) { ...

In the last post we talked about needing some Expression<T> background. There is a lot of good information out there about Expression<T>, but if you haven’t heard – this class is pure magic. If you want a long version of the story, see “LINQ and C# 3.0”. For a short version of the story, read on. .NET compilers like the C# and VB compilers are really good at converting code into an intermediate language that the CLR’s JIT compiler will transform into native code for the CPU to execute. So if you write the following …Func<int, int> square =...

In a previous post, I talked about modeling flowcharts with C# code. The flowcharts are designed, documented, and standardized  by a non-profit  organization charged with measuring the quality of patient care inside of hospitals. They do so by looking at common cases that every hospital will see, like heart failure and pneumonia patients. The logic inside each flowchart can determine if the hospital followed the “best practices” for treating each type of case. Some of the logic becomes quite elaborate, particularly when evaluating the types of antibiotics a patient received, and the antibiotic timings, relative orderings, and routes of administration....

Tim Mallalieu, PM of LINQ to SQL and LINQ to Entities, recently announced: “…as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios.” Tim later tried to clarify the announcement in a carefully worded post: “We will continue make some investments in LINQ to SQL based on customer feedback.” Although Microsoft may not remove LINQ to SQL from the framework class library just yet, they do appear to be treating LINQ to SQL as an experiment that escaped from the lab – something to minimize until it’s erased from...

A few months ago I worked on a system that was based on a set specifications that included some gnarly flowcharts (see pages 7 – 17 for an example). The good news was that the specs were concrete and readily available. The bad news was that the specs change every 6 months. I explored a number of options for modeling the logic in the flowcharts, including WF, WF rules, and code generation from XML, but ultimately decided on staying as close as possible to the flowcharts with C# code. Maintainability and testability were the keys to survival. The end...