Something that frequently gets overlooked in C# are Literal Strings or Verbatim Strings. These are strings like any other except that none of the usual escape characters work. You may think, “Well that just sounds like a broke string”, but that’s the point.

Some times you don’t want a backslash to escape the characters in your string. For example when writing paths in Windows to a file or folder.

//This causes issues because S is not a valid escape
//and t is valid but you don't want to insert a tab in your string.
s = "C:SomePathThat you wantto use";
//Escaping the slashes hurts readability and is aggravating to update
s = "C:\Imagine\lots\of\sub\directories";

The same is true when trying to write regualar expressions. The symbols to represent digits (d) and and word characters (w) are not normally valid escape characters.

//Using d and w in a regular string will stop your code from building.
r = new RegEx("Jonny (d) is "(w+)"");
//Further more escaping the slashes in a RegEx can make the sting hard 
//to read or even more confusing to people who don't use RegEx-es.

The solution is to decorate the string with an ‘at’ symbol and turn it into a string literal or verbatim string. What that dose is ignore the slashes in your string so that they can be used literally. Ironic, i know…

//All of these strings hurt the eyes less, build and, in all 
//cases except the regular expression, no longer intimidate
s1 = @"C:SomePathThat you wantto use";
s2 = @"C:Imaginelotsofsubdirectories";
//Notice since '' no longer escapes we prefix the " with a "
//That's the only quark, i swear.
r = new RegEx(@"Jonny (d) is ""(w+)""");

Yeah, it’s a simple thing, but lots of people don’t seem to know it. So learn it, use it and make suggest others use it.

I like new features in programming languages that enable more flexibility or encompass features for a frequently used patter. A good example is foreach. This was a basic pattern that eventually was incorporated into the syntax of many languages. That being said, I am cautious of change for the sake of it.

Some nice things about C# 3 and .Net 3.5 are LinQ and lambdas. LinQ moves C# and .Net toward extending array objects in what I believe is their next natural abstraction, collections, and providing the tools to effectively manipulate them. I have used lambdas for simple delegates and in a testing pattern I was using with threads. However almost all of the time when I try to re-factor code into a lambda I end up asking why not just make this a function call?

The Case Against Lambdas when not filling in LinQ parameters.

I come across primarily two arguments when talking about lambdas and debating their use in code.

One is that they don’t end up saving any space v.s. refactoring to a separate function. If you count line by line you can usually save a static one or two lines which in the grand scheme is not very significant.
Also the other disadvantage is that they don’t exist outside the scope of where they are declared. A separate function would and could have access modifiers applied like Private, Public, or Protected applied to control is visibility even more.

Another issue is that some programmers are not used to reading code with lambdas in it. They don’t understand their scoping and the object lifetime issues they could complicate. With this argument I like to try and imagine it being used when foreach was added to the language. Honestly this can be said about a lot of features of C# including the using statement.

The case for Lambdas

I am a really big fan of don’t repeat your self. So I frequently refactor code if the same logic or lines shows up two or more times. When the logical scope of the code is extremely local, I think lambda. Other wise it would qualify for being factored into a function. One pattern I have used is when there is a logical section inside is also performed either once before or after the loop.

//Logic before loop
localtemp = source.GetSomeValue();
localCollection.Add((localTemp + anotherLocalVar) / yetAnotherLocal);

while(source.IsActive)
{
	//Keep looping till no longer active
	localtemp = source.GetSomeValue();
	localCollection.Add((localTemp + anotherLocalVar) / yetAnotherLocal);
}

We have two approaches to this. One would be to re-factor it to a function that would be local to the code, probably protected or private in the same class. The other option is to use Action() to make it a lambda. Lets look at both starting with moving the code to a function.

private void RefactoredActions(object source, object collection, object extra, object divider)
{
	object localtemp = source.GetSomeValue();
	localCollection.Add((localTemp + extra) / divider);
}

// ... ... ... ...

//Logic before loop
RefactoredActions(source, localCollection, anotherLocalVar, yetAnotherLocal);

while(source.IsActive)
{
	//Keep looping till no longer active
	RefactoredActions(source, localCollection, anotherLocalVar, yetAnotherLocal);
}

This would work but the number of parameters can get quite large if there is a lot of interaction in the loop logic with other locally scoped variables. The code is now located in one place and any updates to the logic can be done once with out injecting any bugs.
Now lets look at it using Action().

//Logic before loop
Action loopLogic = () =>
{
	object localtemp = source.GetSomeValue();
	localCollection.Add((localTemp + anotherLocalVar) / yetAnotherLocal);
}
loopLogic();

while(source.IsActive)
{
	//Keep looping till no longer active
	loopLogic();
}

This is where a Action() can end up refactoring the code into a concise call. This works because everything in the lambda exists in the in scope local to the loop. The syntax can be much cleaner and scope of understanding various parts of the code is reduced.

Conclusion

Though personally the cases where I have adopted lambdas are small. They can be useful in your code. New paradigms should not be adopter or shunned because they are simply new. They should be used based on their features and function. This is one case where I have found lambdas have helped and I hope you find it useful and welcome you comments and understandings.

One thing that can git in the way of expressing an idea in code is overly verbose syntax. The trinary operator in is perhaps the most overlooked way to concisely express the same code with out losing any of it’s safety. Code should be blunt.

One example I find the ternary operator useful is when parsing data from strings. The usual pattern looks like this.

int temp;
if (int.TryParse(toParse, out temp))
{
    someObj.Prop = temp;
}
else
{
    someObj.Prop = 42; //Default value
}

This pattern shows up when you have to parse a string and assign the value to a property on an object. You can’t pass properties as an out parameter so you have to make a temp and then check the result of the parse. Also you can’t assign the default value directly to temp because int.TryParse will replace temp with zero on failure. So you have to assign temp a default on failure.

The less complicated solution using the ternary operator…

int temp;
someObj.Prop = int.TryParse(toParse, out temp) ? temp : 42;

The ternary operator works by evaluating a condition. If that is true it use the value after the question mark. Else it will use the value after the colon.

int someTarget = (someTest == someValue ) ? ifTrue : ifFalse;

If your vars have succinct names this can be a much easier to read statement than the original. If it gets too long you may want to move it to two or three lines. If you have to go to more than that keep what your started with. Code should always be clear first, and if that means shorter all the better. You should have the ternary operator in your programmers toolbox as it is in most C syntax derivative languages. It almost always makes for clearer code when not nested, shutter.

This trick is also helpful when parsing XML.

For anyone who has used a fair amount of threads is familiar with the having to synchronize their work or access to shared resource. This is typically done with semaphores or other locking methods to control when and how many threads access the critical sections of your code. The C# lock statement is very nice in that it allows you to wrap code that is shared between threads in a lock statement and insures that if there are any errors thrown that they will be taken care of.

lock (_lock)
{
    //Critical code goes here
}

I was re-factoring some properties in a class that locked on set and get. I started thinking that it would be nice to be able to have a way to share reading from the get prop while locking whenever a set prop was used. I also wanted to avoid exploding the code into some sort of eye trauma for next time someone would have to look at it.

There is a class for concurrent reading and exclusive locking of critical code called ReaderWriterLock. This class was specifically what I was looking for in my re-factoring but it had a down side.

What was once this:

//Vars with an _ are private and in scope
public string SomeString
{
    get { lock (_lock) { return _someString; } }
    set { lock (_lock) { _someString = value; } }
}

Now looked like this:

public string SomeOtherString
{
    get
    {
        _rwLock.AcquireReaderLock(Timeout.Infinite);
        try 
	    {
            return _someString;
	    }
	    finally
	    {
            _rwLock.ReleaseLock();
	    }
    }
    set
    {
        _rwLock.AcquireWriterLock(Timeout.Infinite);
        try
        {
            _someString = value;
        }
        finally
        {
            _rwLock.ReleaseLock();
        }
    }
}

The try finally blocks are needed if anything were to go wrong in the critical section of the code. When manually setting the locks when using synchronization objects it is necessary to release them or all other threads waiting for the lock will never continue. That’s the really nice things about the lock statement. You don’t need to manually release it and it will unwind even if there are exceptions. There is another statement in C# that also works like this, and it is the using statement.

Using works by putting an object in the context of the statement and no matter what happens the dispose function for that object will be called when execution leaves that scope. This is really useful when calling into DLLs or objects that need to release resources like file handlers or sockets. I figured if I had an object that could lock my code for me then I could use it in a using statement and have the dispose function release it for me.

The prototype for the object looked like this:

/// <summary>
/// This class acts as a lock with an option to set it to either
/// reader for a concurrent lock or writer for a exclusive lock
/// </summary>
class Locked : IDisposable
{
    private ReaderWriterLock _rwl;

    /// <summary>
    /// Setup a lock for reading/writing with guaranteed tear down
    /// </summary>
    /// <param name="rwl">The ReaderWriter object to coordinate locking</param>
    /// <param name="writer">True if blocking write, false otherwise</param>
    //Not sure default parameters are supported in .Net 3.5
    public Locked(ReaderWriterLock rwl, bool writer = false)
    {
        _rwl = rwl;
        if (writer) _rwl.AcquireWriterLock(Timeout.Infinite);
        else _rwl.AcquireReaderLock(Timeout.Infinite);
    }

    /// <summary>
    /// Releases the lock when the class is used in a using statement
    /// </summary>
    public void Dispose()
    {
        _rwl.ReleaseLock();
    }
}

With this object I could now put the shared code in using statements and make sure I never ran into any deadlocks because of unforeseen exceptions or cases where execution some how never called a release. This also allowed me to allow multi-read and single write access to the property as well.

The end code looked like this:

public string SomeString
{
    get { using (new Locked(_rwLock)) { return _someString; } } 
    set { using (new Locked(_rwLock, true)) { _someString = value; } }
}

Keep in mind that creating the object adds overhead but the advantages here are readability and removing the possibility for deadlocks. Also in debugging the Locker class is a good place to put logging or debugging statements instead of having to add them to each lock when searching for an issue. I though this was a really good way to leverage some of the features and paradigms of the language to solve a re-factoring issue I ran into. Hope you find it useful too.

There are many other useful classes for synchronization like the Monitor Class and a Win32 blocking call that dose execute in Kernel time but I plan on writing about those in the future.