Tag: development

A Simple CSV Export?

The following programming anecdote was posted by a former colleague on his Facebook page today:

A couple of years ago a fellow developer was asked to take some data and export it to CSV format. He took some time and researched a library. After, the manager/architect/lead developer (all the same person), questioned why he took that time, and why he didn’t just string.Join() them together and move on. He rattled off a few special cases, escaping characters etc. and stood by his decision though the person questioning still thought it a poor one.   About once a month since then I hear a new story about home-grown, handmade CSV functionality breaking because it didn’t account for a case, character or something previously unexpected.

It’s a reminder to me that no matter how simple the task appears to be, a thought should be given to it’s longevity, future usage, and potential expectations long after the initial case for creation has been forgotten. A small investment now can go a long way.

“The only way to go fast is to go well”   For those curious, the chosen library at the time: http://kbcsv.codeplex.com/

Well said.

.NET String Concatenation

String concatenation is a tool on every developer’s tool belt but in .NET there are multiple ways to accomplish it. There are also a lot of conflicting articles, posts, etc. on the subject. When should you use StringBuilder? When should you use string formatting? This article will hopefully shine some light on when to use each method.

Which Methods Were Tested?

How Were They Tested?

A console application was prepared to test operation scenarios. The scenarios were timed using the System.Diagnostics.Stopwatch class. The full Visual Studio solution can be found in my CodePlex project.

What Were the Results?

Scenario 1: Loop Concatenation

The Loop Concatenation scenario was built to test string concatenation within a loop. This data set had the most straight-forward results. The StringBuilder class gives the best performance when using concatenation in this scenaraio.

Loop Concatenation Results (in milliseconds)

Code sample using StringBuilder in this scenario:

var builder = new StringBuilder();

for (int i = 0; i < this.iterations; i++)

var testString = builder.ToString();

Scenario 2: Full Name Concatenation

The Full Name Concatenation scenario was built to test simple string concatenation in which few concatenations occur. It concatenates first name, a space, and last name. This is commonly used to build display names for a UI. These results point to the String.Concat method as the most efficient way to concatenate small numbers of strings.

Full Name Concatenation Results (in ticks)

Code sample using String.Concat in this scenario:

string first = "John";
string last = "Deaux";
string fullName = string.Concat(first, " ", last);

Scenario 3: Long Text Concatenation

The Long Text Concatenation scenario was built to test long concatenations in which many concatenations occur. It simulates building the body of an email message. These results also point to the String.Concat method as the most efficient. Comparing the prior scenario with this scenario you can begin to see pattern. As you add concatenations, the efficiency of String.Format and StringBuilder (when out of a looping scenario) declines.

Long Text Concatenation Results (in ticks)

Code sample using String.Concat in this scenario:

string newLine = System.Environment.NewLine;
string name = "John Deaux";
string email = "john.deaux@123.me";
string subject = "The Subject of the Message";
string product = "ABC";
string feature = "XYZ";
string body = "The comment(s) made about product/feature.";

string[] values = new[]
        "Name: ", name, newLine,
        "Email: ", email, newLine,
        "Subject: ", subject, newLine,
        "Product: ", product, newLine,
        "Feature: ", feature, newLine,
        "Message: ", newLine, body

var emailBody = string.Concat(values);

Scenario 4: Date Concatenation

The Date Concatenation scenario was built to test the formatting of dates. It formats a date into the sortable format of 2011-12-31T15:30:15. Of the people I’ve talked to about this little experiment, this one has surprised the most. Why? Because it is highly touted by articles, books, and even Microsoft as the way to format data and it’s extremely inefficient. The String.Format method is slower and less efficient than every other method tested, including the StringBuilder class, for formatting DateTime objects as strings.

Date Concatentation Results (in ticks)

Code sample using String.Concat in this scenario:

DateTime date = DateTime.Now;

var values = new[]

var sortable = string.Concat(values);

Yes, you did read that correctly. The above code is a lot faster and more efficient than:

var sortable = string.Format("{0:u}", DateTime.Now);
// or
var sortable = string.Format("{0:yyyy-MM-ddTHH:mm:ss}", DateTime.Now);

Back to Basics: System.String

For such a simple concept, the string class is, in my opinion, one of the most complex classes in the System namespace. The MSDN page for String Class is 53 printed pages excluding the 2 additional pages of comments.

What is System.String?

In the .NET framework, the string type is a reference type. It is not a value type as is often the belief. It is an object that consists of a collection of System.Char values in sequential order. Characters within the string can be referenced as follows:

string foo = "bar";
char r = foo[2];


The string type is also immutable. You cannot change the contents of a string without reflection or unsafe code. The methods, operators, etc. that appear to modify a string actually return a new string with the modified contents. The Replace function of the string object is a great example of this. You cannot simply call the Replace method. You have to return the results of the method to a string variable.

string foo = "abc";
foo = foo.Replace("abc", "xyz");

Concatenation and the Compiler

The compiler does some interesting things when working with strings. For example, when concatenating with variables in a single statement:

string foobar = foo + " " + bar;

// compiler sees the above as:
string foobar = string.Concat(foo, " ", bar);

When you use constants such as literals and const string members, the compiler knows that all the parts are constant and it does all the concatenation at compile time, storing the full string in the compiled code.

string foobar = "foo" + " " + "bar";

// compiler sees the above as:
string foobar = "foo bar";
const string foo = "foo";
string foobar = foo + " " + "bar";

// compiler sees the above as:
string foobar = "foo bar";

String.Empty versus “”

And finally, there is a difference between string.Empty and “”. When you use “”, .NET creates an object but when you use string.Empty it does not. The difference may be small, but its a difference that can make a performance impact.

string foo = ""; // creates an object
string bar = string.Empty; // doesn't create an object

Null Coalescing Operator

In C# 2.0, Microsoft introduced the null coalescing operator (??). The ?? operator is a shorthand notation for returning a default value if a reference or Nullable<T> type is null.

The examples below show how the null coalescing operator achieves the same result as traditional conditional statements but with less lines of code. Both sets of examples use property getter methods with assumed fields.

Reference Examples with Conditional Statements

public MyObject MyObjectProperty
        if (this.myObject == null)
            return new MyObject();

        return this.myObject;

Reference Examples with Null Coalescing Operator

public MyObject MyObjectProperty
        return this.myObject ?? new MyObject();

Nullable<T> Example with Conditional Statements

public int Number
        if (this.nullableNumber.HasValue)
            return this.nullableNumber.Value;

        return 0;

Nullable<T> Example with Null Coalescing Operator

public int Number
    get { return this.nullableNumber ?? 0; }

The main argument against the ?? operator is that developers don’t understand it so it makes the code less readable and maintainable. This is a poor argument in my opinion. As developers, we should never stop trying to improve both ourselves and our teams. This is something that can be taught over lunch one day.

More reading: ?? Operator (C# Reference) – MSDN