It’s difficult to imagine what the author was thinking. I’d like to believe it’s a contrived example, but I’ve seen similar code. This method could easily be reduced to public boolean isBooleanFalse(boolean value) { return !value; }. Better yet, calls to the could be replaced with !value.

Why do programmers write code like this? My first thought was blame the programmer for not having learned how to use the ! operator. Or maybe it’s Martin Folwer’s fault for publishing the Replace Temp with Query refactor that recommends trivial methods like this. However, I think part of the responsibility falls on antiquated best practices and coding standards, like those left over from K&R C.

An Assistant Professor of Psychology at Stanford, wrote, “one’s native language appears to exert a strong influence over how one thinks.”[pdf] It’s reasonable to extend this conclusion to programming languages. The style we use and the coding standards we follow affect how we solve problems.

Consider how reversing the following guidelines push the suspect code snippet closer to the optimal solution.

Declare variables at the top of methods

By habit, some C programmers declare and initialize variables before the first instruction. One of many side effects is that temporary variables seem to be created early in the processes, leading to variables that are not necessary.

Single exit point

This single exit point practice states that there should be a single return. The optimal version of this method requires only one return. However, adding a return to each case of the if-else would remove the temporary variable, leading the programmer one step closer. There are coding standards today that still forbid this.

No ternary operators

Some organizations hire developers that can’t grok (expression) ? true : false;, so they forbid it’s use. The ? operator is abused, but so are switch statements, inheritance, reflection, and function pointers.

Not using Booleans like Booleans

C added bool over a decade ago, though some developers are still waiting to use them. Since these guys are typically using integers, the correct expression is if (MyBool == OVERLOADED_TRUE), rather than the more concise if (MyBool). These developers even bring this style into Java and C#, without considering why it existed.

These apply less today than they did on mainframes in 1978. Not only do they add noise, they also hinder our problem solving abilities. I’m not advocating the use every good tool or pattern that comes along, but we need to be more skeptical of long standing conventions.

From The Library of Congress, via Flickr

.NET developers should consider replacing guard clauses with code contracts.

Guard Clauses

Kent Beck or Martin Fowler championed Guard Clauses. There aren’t many excuses to write functions with many levels in indentation.

Advantages

• placement makes it more obvious that these are preconditions (xUnit Patterns)
• “the guard clause says, ‘This is rare, and if it happens, do something and get out.’”, Martin Factor in Refactor
• avoids the arrow anti-pattern

Code Contracts

Microsoft Code Contracts provide a better alternative for software using .NET.

Advantages

• same benefits as guard clauses
• declarative
• can be statically verified

Old way

New way

Thanks Zach.

To compare LINQ to non-LINQ implementations, we must measure the execution time of each. If you’re a Computer Scientist type, you know we can analyze our algorithms using big O notation. One problem with this is that it requires having the LINQ source code. It also ignores the other potential costs, like increased function calls.

Intersection Results

The last post compared the maintainability of four methods that computed the intersection of two sets. The following graph illustrates how the run time increases as the set sizes grow.

Our goal is to compare the examples, so the curve of each line is more important than the actual times and set sizes.

What does the graph tell us?

• The nested foreach is slow, because as the set size increases, the execution time increases exponentially.
• The highly tweaked sort first algorithm out performed the LINQ query.
• The LINQ call (IEnumerable.Intersect) outperformed them all.

So for this example, the call to IEnumerable.Intersect is both the simplest and fastest approach. If didn’t already exist, the verbose sort first would be our fastest option.

How to measure performance

We need to write some code to exercise the different algorithms we want to compare. To produce the graph above, I used C# and the System.Diagnostics.Stopwatch.

For each set size on the graphs x-axis, we run each function against a random set of values. The range and distribution of the values in the set should be tailored to your needs.
To get a nice smooth curve, each test should be executed thousands of times (I did 100,000), and then an average should be taken.

There is one caveat. LINQ uses lazy evaluation, which means that the query is not performed until it is need. So if you want to time the query, you need to invoke the query. The IList.ToArray() method does this.

LINQ hides the gory details of how algorithms work, making code measurably more maintainable. Maintainability is correlated with both cost[pdf] and defects[pdf]. In the following example, we’ll use Visual Studio 2010 to measure maintainability.

Set Intersection

Imagine we have two sets of integers, and we need to find the intersection – that is, numbers that are in both sets. In addition, the intersection set should not contain duplicates. Below are four C# functions, followed by a comparison of their maintainability indexes.

Function 1

A junior developer might begin by taking each number in set A, and searching set B for that number. The C# code for this might look like:

Function 2

A more senior developer might review Function 1 and notice that it is slow when operating on large sets. There are three nested loops, including the .Contains, which is great than O(n2) complexity.
A more efficient solution would be to sort both sets first, so that we can find the intersection using a single loop. For example:

This is the type of code that gives the author pride, and the maintainer a headache. It may be fast, but the intent is not obvious.

Function 3

Now let’s try a query using LINQ.

Note that this function creates a nested loop. For each number in set A, we must search for it in set B.

Function 4

Fortunately, LINQ already contains a number of basic math operations, including intersect. For example:

Maintainability

The LINQ functions appear to be the most maintainble. However, we need a more systematic approach. Starting with Visual Studio 2008, the Visual Studio now includes a static code analysis tool, which we can use to compute a maintainability index. These numbers range from 0 to 100, where 100 is the most maintainable. I’ll discuss how this works in a future post.

Using Visual Studio 2010 Ultimate RC1, we get the following results:

These metrics show that LINQ does produce more maintainable code. In the next post, we’ll measure the performance of each algorithm.

Microsoft LINQ integrates queries directly into .NET languages, making it easy to work with collections. The best part about LINQ is that it allows us to say what we want to do to a set, without telling it how. This decreases code complexity, without losing any functionality.

For example, say we had the following function:

We could read this roughly as, “Create a temporary collection.  For each number, if it is greater than two, add it to a collection to be returned.  Finally, return the temporary collection.” This isn’t a bad method, but it could be better. Using LINQ, we can rewrite it as:

Now, we have “return every number greater than two.” Note that it states what will be returned, not how. In the net post, we’ll actually measure the maintainability of each approach.

What sort of performance cost do we pay for the luxury of LINQ?  When performance matters more than maintainability, we must develop tests to determine the best solution. In the upcoming posts, we’ll learn how to quantify LINQ’s impact on both performance and maintainability.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.Donald Knuth