Recently I read an article from Jeff Atwood, where he basically claimed the brevity leads to better code. Personally I think his example he gave:

if (s == String.Empty)
if (s == "")

Is just plain wrong, and this is the comment I put on his website:

I think this is a very bad example using “” and String.Empty. Because essentially “” is a magic number of sorts, I am talking totally theoretical here, I know that “” is never going to change from representing a empty string, but what happens when developers start using “\n\r” instead of Environment.NewLine, not only does it cause a problem if you move to Mono on Linux it also requires a higher knowledge level to understand what “\n\r” means and you even have to remember what order it goes in.

It is good practice to get developers thinking that magic values such as “” and “\n\r” and any number is not the right way to code. Because if you tell them it is okay to use “” then why is it not okay to use 3.14F for PI instead of using Math.Pi?

It’s all about staying consistent and having the least amount of rules as possible, that is how you keep code simple across your organization.

Also by your same logic a developer should never use VB.NET because the language is way to verbose. I personally am a C# developer, but if a person is more productive in VB.NET and it meets the requirements for the project who am I to tell them they should use C# because it is less verbose.

The ?? operator returns the left-hand operand if it is not null, or else it returns the right operand.

int? i = null;
int count = i ?? 0;

The value that count is set to is 0. The ?? operator is short hand for:

int? i = null;
int count = i.HasValue ? i.Value : 0;

Or

int? i = null;
int count = 0;
if (i.HasValue)
	count = i.Value;

The Understanding C# series at Coder Journal will be an on going project to help the readers to better understand the C# programming language that doesn’t get covered except at the more advanced levels.

Unit testing is an important part of developing high quality software. Many of you are probably not familiar with the term Unit Testing. Wikipedia defines Unit Testing as

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, web page, menu etc, while in object-oriented programming, the smallest unit is always a Class; which may be a base/super class, abstract class or derived/child class. Units are distinguished from modules in that modules are typically made up of units.

One of the most popular ways to Unit Test .NET code is NUnit. However, I am not going to get in to the basics of Unit Testing in this post. If you are interesting in learning more about NUnit and Unit Testing please visit NUnit QuickStart page. This post is going to deal with how does a developer test a class that has a private or hidden constructor.

Private constructors are very useful tool in a developer arsenal, because there are many instances when you want to give the consumer of your code access to the object but not the ability to create it. I have provided an example below:

public class Customer
{
	public static Customer GetCustomer(int customerId)
	{
		// get information from database
		Customer customer = new Customer(customerId, database.GetString("CustomerName"), database.GetDecimal("CustomerAccountBalance"));

		return customer;
	}

	internal Customer (int id, string name, decimal accountBalance)
	{
		// set customer properties
	}

	public int Id { get { return _id; } }

	public string name { get { return _name; } }

	public decimal AccountBalance { get { return _balance; } }

	public void DebitBalance (decimal amount) { ; }

	public void CreditBalance (decimal amount) { ; }
}

There is no real way to test the constructor of this Customer object unless you embed your Unit Tests right in your code. But personally I find that method sloppy because you are mixing QA and Development together, and they should be seperate to at least maintain good software development practices.

If you were to create a Unit Test in the same assembly as the Customer class above, it would look something like this:

Customer customer = new Customer(/* ID */ 20, /* Name */ "Joe Customer", /* Account Balance */ 3400.0M);

// credit the customer $30.00
customer.CreditAccount(30M);

// assert that the original account balance plus the additional credit are equal
Assert.AreEqual(3430.0M, customer.AccountBalance);

But this isn’t very useful if you want to separate your code from your tests. So what is needed is a way to instantiate a private method from outside an assembly. So in order to solve this problem I created the following code that I use in all my Unit Test Projects for just this circumstance. (note: The following code is not for the faint of heart. It combines generics and use of the reflector namespace).

using System;
using System.Collections.Generic;
using System.Reflection;
using System.Security.Permissions;

public static class TestHelper
{
	public static T CreateInstanceForNonPublicConstructor<T>(params object[] parameters)
	{
		List<Type> constructorSignature = new List<Type>(parameters.Length);

		// add all the types in order of the parameters to create the consturctor
		// signature so that the correct constructor can be retreived
		foreach (object parameter in parameters)
			constructorSignature.Add(parameter.GetType());

		ConstructorInfo typeConstructor = typeof(T).GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic, null, constructorSignature.ToArray(), null);
		return (T)typeConstructor.Invoke(parameters);
	}
}

In order to use this code to instantiate the Customer class above, in an external assembly, the same Unit Test from outside the assembly would look like this:

Customer customer = TestHelper.CreateInstanceForNonPublicConstructor<Customer>(new object[] { /* ID */ 20, /* Name */ “Joe Customer”, /* Account Balance */ 3400.0M });

// credit the customer $30.00
customer.CreditAccount(30M);

// assert that the original account balance plus the additional credit are equal
Assert.AreEqual(3430.0M, customer.AccountBalance);

So I have demonstrated that it is possible to fully test all objects from an external assembly using standard Unit Testing as well as keeping your code separate from your tests and upholding good software development practices.

Update: It wasn’t very clear that this code can apply to any type of constructor (public, private, and internal), this code I have in TestHelper can be used in any development process you need it in, I have just chosen to apply it to Unit Testing.