Classic Case

As developers, time to time we have to deal with text cases in our code.

Not that we always have to do it, considering that some UI platforms, like HTML/CSS will do this for us:

To my surprise, I didn't find this same level of support in WFP/Silverlight. Granted, you can mark your <TextBox> with  CharacterCasing="Upper" or "Lower". But no support for Title Case!!! . And no support for other controls, like TextBlock, etc. !

But we play with text cases not only for output. Traditionally some of us do case transformations for case-insensitive compassion, which is wrong on so many levels:
First of all, even if you have to use ToLower or ToUpper method, it is a good practice to pass CultureInfo as a parameter. Your server may use one culture, but web request may come with a different culture! By passing culture info into formatting and case transforming methods you ensure that your customers will see what they suppose to see:
Don't get me wrong, this code is still bad - it is just marginally better then before. First of all, what if arg is null? Or str is null? Sure, we can add those checks, but it will make code even less readable.
Fortunately, .NET provides us with nice alternative: System.String static methods like Equals, Compare, Format, Join, etc.
So our code can look like this:
Actually it even runs significantly faster!!! And it is smart enough to take care of special characters !!!:

But if you want to be 100% sure that you are producing the right result, don't rely on System.String.Equals function - use System.String.Compare instead. It takes Culture as a parameter and guaranteed to perform checks according to provided culture rules.

CultureInfo is a very interesting class, it provides you with all information necessary to display your information correctly in different cultures and languages.

Here is the hidden gem that I found that can be used to To Display Dynamic String In Title Case:

So, bottom line:

• Use static methods of the System.String with Culture information for string comparison.
• Use CultureInfo's methods to UpperCase, LowerCase and TitleCase conversions.

Happy Coding!

Shameless plug: if you have to deal with SQL Server performance investigations, try my free web-based tool: http://supratimas.com

All about Lazy

Software Engineers are lazy. It’s a fact.  And it is a good thing.

Lazy engineer would not copy same code over and over, she’ll extract it as a method. Lazy engineer will use a standard .NET feature (tested!) instead of rolling out his own.
Of cause we talk about good engineers. Not so good and lazy engineer will copy code around, causing support nightmare.

BTW, Visual Studio allows you to find this type of code clones: just right-click on the code block and select “Find Matching Clones in Solution”.

Later on, TFS, SVN or GIT will help you to identify those who code like that.

But enough about lazy engineers, today we are going to focus on lazy property initializes.

Let’s take a look at the typical object, that exposes a public property of collection type initialized on-demand:

SomeStrings property would be initialized when it gets accessed for the first time. So far so good.

But imagine you have 5 or 10 properties like that on a class. It is a lot of typing… (remember – lazy!)
There is a way to slightly minimize typing by using ?? operator

The ?? operator is called the null-coalescing operator. It returns the left-hand operand if operand is not null; otherwise it returns the right hand operand. So our property code can be changed like that:


But what if we have to make this property accessor thread safe?

At this point, we have a choice:  we can try to implement thread-safe property initialization yourself, like in this HorrobleObject.
I’m pretty sure I've done it right this time,  but I wouldn't bet on it.

It is possible that I missed some subtle nuance and it is going to bite me later.

So please, don’t use this code.

Fortunately for us, lazy but smart engineers, .NET framework offers the solution:

public class System.Lazy<T>

Using this class we can rewrite our code like this:

Lazy object is ideal for a singleton pattern, if you really have to have one.

It allows you to focus on business logic of you class, and not to be sidetracked by low-level details of thread-safe initializers.

Stricktly speaking, Lazy can be used not only in thread-safe scenarious, but in a regular code as well. You can indicate None, as threading mode and in this case Lazy will run without multy-threading overhead.

So, if you need to implement on–demand property initialization in your class, especially in thread-safe fashion, I strongly suggest you to use Lazy<T>!

And if you want to know, what it does under cover, you can take a look at its ~400 lines of code implementation here: http://bit.ly/1gaWjOm

Introduction of the series

Writing code is an exciting business. At least it always been like that to me. It is fast and ever-changing business.

Every day talented people strive toward making software faster, more stable, more secure. And at the same time, even more talented people are looking for ways to break it :-)

Hardware manufactures come up with new components that open up possibilities that were unimaginable just a several years ago. And at the same time these advances make certain ‘industry standard’ patterns and practices dangerous and obsolete.

Keeping up with technology is very important for any kind of engineer, but for The Software Engineer it is an absolute necessity.

Every one of us have a favorite way of doing things and but time to time we have to re-evaluate our coding habits.

In this (hopefully) weekly blog I’m going to illustrate patterns, practices, code snippets that I find interesting, dangerous, cool, exciting ,etc.

Just to illustrate my point, I’m going to give you a simple example. I’m pretty sure that every one of you ​already knows about this coding pattern and never ever write code like that. You don’t, don’t you? ;-)

So, 11 years ago, in .NET 1.1, this snippet was perfectly fine:

but later, someone decided to upgrade to .NET 2.0 and use modern Dictionary object in initialization. This code still works, as expected:
 
But sometime later, when new developer decided to use modern initialization pattern and made a small change to the code, just replaced IDictionary with var: then BOOM, code no longer works:
 
The reason code used to work before and not anymore is that implementation of the Dictionary class is backward compatible, when casted into IDictionary interface, but when it is used directly, this class produced an exception, as it supposed to do.

But let's say that you are not aware of this change, and you keep writing code that relies on dictionary to return null, when key is not found. Yes, of cause if you have a solid set of unit tests to cover every line of your code and every possible combination, then you’ll see this problem right away. But we all know that unfortunately it is not a reality and code like that can sneak into production.

So the new, modern code should probably look like this:
 
As I said, this example is trivial, but nevertheless important to remember.