Tuesday, March 23, 2010

Usage Of The "is" Operator Should Be Handled With Care

C# provides means to explicitly cast from a type to another type. If you want to cast from float to int you can use the (int) cast operator to acheive that. This operator simply says to the compiler, I know you don't like this, but, please let the runtime try to do the cast. This operation can either succed or result in an System.InvalidCastException to be thrown.

In addition to this, you can overload the explicit cast operator in case you wanted the cast to happen by your own defined rules. Ok let's see an example of this. Suppose that we have two types, Human and Employee, and in our very unfair world, an Employee is not a Human! The layout of these two classes might look like this:

public class Human 
    {
        public string Name { get; set; }       

    }
    
    public class Employee 
    {
        public string Name { get; set; }

        public string Job { get; set; }

        public override string ToString()
        {
            return string.Format("Employee: {0} is {1}", Name, Job);
        }
    }

Now let's say that you want to support an explicit custome conversion from Humans to Employees -for a fictious rule, let's say that every human is unemployed employee. The human class after adding the conversion operator should look like this:
public class Human
        {
            public string Name { get; set; }
            public static explicit operator Employee(Human h)
            {
                return new Employee()
                {
                    Name = h.Name,
                    Job = "Happily Unemployeed"
                };
            }
        } 
 

You can now try to cast your Humans to Employees, and see if the cast is really applying your rules, here's how I might attempt to cast one of humans to employee:
Human h = new Human {Name = "John"}; 
            Employee s = (Employee) h;
            Console.WriteLine(s);

If you run this code you should see the output on the console screen saying:

Employee: John is Happily Unemployeed.

Now let's see how this plays with the famous "is" operator. The is operator is binary operator with a return type of boolean. What it does, is that it checks to see if the left hand operand is actually of the same type of the right hand operand -By the same type here, I mean, the same as an instance of the same class, or an instance of a derived class, or an instance of a class the implements the right hand operand in case the right hand operand is an interface.

Here's a simple example to see this operator in action:

bool shouldBeTrue = "Hello" is string; // true
bool shouldBeTrueToo = "Hello" is object; // true
bool shouldBeFalse =  "Hello" is ICollection; // false

Now, the interesting part:
bool shouldBeWhat = new Employee() is Human; // ?? guess guess

Pause a minute and think of the above statement. What should the value of "shouldBeWhat" be? True of False? ...

OK, the value of the boolean variable "shouldBeWhat" will actually be false. Yes, Employees are not Humans! Even though you have provided an explicit cast rule that , by the virtue of its existence, states that humans can be employees. "can be" doesn't equal to "is", does it? So, yeah the is operator doesn't take in account your explicit casting operators. So this is the first gottcha!

The second point I wanna mention is that, the "is" operator works by actually performing a cast. Yes it casts and checks if the cast succedes it returns true otherwise, it returns false. A typical usage of the is operator is probably as follows:

if(h is Employee)
            {
                var x = ((Employee) s).Job;
            }

This should look familiar to you, a typical pattern when using the is operator is by checking first if a variable is of a given type, then if it is, cast it to that given type and use it. How many casts does the above code segment contain? 2 is the answer! Yes two, one is obvious in the statment
var x = ((Employee) s).Job; 
and the other one is, yeah you guessed it, the cast performed by the is operator. This is not very ideal, as it simply, adds an overhead of a second cast which should is not necessary. So, what should you do to avoid that second cast?

Use "as" instead of "is":

The "as" operator allows you to do safe casts and aslo avoid the probability of throwing any InvalidCastException, by assigning null to the variable if the cast failed. The following segment is semantically equivalent to the previous segment, but is considered faster and safer:
var x = h as Employee;
if(x != null)
 string job = x.Job;

The above segment is faster because it includes only one cast.

Conclusion:
There's not much to say here, just deal with the is operator carefully, and if possible avoid it and use the better alternative "as" operator.

Sunday, March 14, 2010

New, But Not So Obvious, Features in .NET 4.0

.NET 4.0 came out lately with a lot of new, cool, and somewhat game-changing features. These features include language features like the famous dynamic keyword in C# and this whole dynamic dispatching thing that made possible by the DLR (Dynamic Language Runtime).There are also some additions on the library level, the parallel extensions is an obvious example of that.

In this post I will mention some of the new additions that are not so well propagated.

First The additions to the string class:
The BCL guys are still working on the core. Apparently they are trying to lessen the number of extension methods that you need to write as a complement to some of the very core, and widely used in any application, classes -Pretty much everyone has a StringExtensions, and DateTimeExtensions dlls.

string.IsNullOrWhiteSpace()
The old string.IsNullOrEmpty() was used to check if the string variable is null or if it's equal to the empty string ("", or string.empty)In many cases a string that contains only white spaces is considered to be an empty string. People used to do the following check over and over again:
if(string.IsNullOrEmpty(s) && s.Trim() != string.Empty)
  {
   // do my job;
  }
Now string.IsNullOrWhiteSpace() is designed to save you that extra Trim call.

string.Join()
Prior to .NET 4.0 string.Join was designed to accept two parameters a separator and an array of string, and it was expected to output one single string that contains the strings in the array separated by the separator. The problem with this is, if you have two separate strings and you want to join them together you would have to create an array and insert those two strings inside the array, then call string.Join passing in your separator of choice and the array. A call should look like this:
string first = "first";
string second = "second";
string[] sequence = { first, second };
string joined = string.Join(" - ", sequence);

New overloads had been added to the string.Join method, one of them accepts a params of objects and it automatically calls ToString, so that you don't have to do that extra step of creating an array that holds your string values. Now the call to the method is simplified:
string joined = string.Join(" - ", first, second);

Modern collections support with string methods
If you examine the old overloads of string methods that accept a collection, you shall find that the only collection these methods accept, is array. With .NET 4.0 things are different, now these methods support IList<T>, ICollection<T>, and IEnumerable<T> (yeah, I know, this should have been possible since .NET 2.0). With this support statments like this are possible:
string joined  = string.Join(" - ", stringList.Where(s => s.Length > 3).Select(s=> s));

Second, Lazy<T>

Lazy Loading, is a technique that implies, creating and initializing expensive objects on demand. Most nowadays ORMs follow this technique when fetching data from the database. The Lazy<T> is a new type introduced in .NET 4.0 that enables you to lazily create your instances and validate whether an instance has been created or not without accidently creating it.For example if I have an object named ExpensiveObject like so:

class ExpensiveObject
     {
         public ExpensiveObject() { }
         public ExpensiveObject(string connection)
         {
             Console.WriteLine("Constructing expensive object");
             Connection = connection;
         }
 
         public string Connection { get; set; }
     }
Here's how I would Lazily create an instance of this object:
Lazy<expensiveobject> a = new Lazy<expensiveobject>();

To check if the object has been already created or not, you can use IsValueCreated boolean propery on the Lazy<T> object:
Console.WriteLine(a.IsValueCreated);
This should print false. If I tried to access the underlying expensive object (through the Value propery on Lazy<T>) and then check to see IsValueCreated, the result should be true:
string  dummy = a.Value.Connection; 
Console.WriteLine(a.IsValueCreated);

This statement should print True on the console window.

Note: In the above example we created an instance of ExpensiveObject using the default constructor. You can create it using a custom consructor by passing in a Func (i.e. any method that returns an expensive object)
Lazy<expensiveobject> custom = new Lazy<expensiveobject>(() => new ExpensiveObject("My Connection"));

Hope this helps!

Monday, March 8, 2010

Programmers And The Value Of Hard Focus

There was a very interesting discussion on reddit a few days ago. Some fresh programmer asked how many pure work hours do programmers work per day?


By pure work he meant, the number of hours spent on (coding/designing/testing, etc.) a task that is probably assigned to him by one of his superiors. Other activities like personal researching, blogging, etc. are not counted.

The question sound pretty interesting to me and the answers came much more interesting.

Most of the answers implied that programmers put less that four hours of pure work per day. This is half the assumed time (8 hours for most companies).

So, why do programmers work less than most of other carriers' professionals? An immediate answer that might came to my mind "well, that's normal because they are sloths lazy." 


False Assumption:
 If I don't work HARD I will eventually fail to finish my work, and will certainly feel incompetent.

There's a lot to programming than HARD work: 
For me, it doesn't matter how many hours I work during the day. What matters most, however, is the number of tasks I manage to finish. This is ths only productivity metric to me, and it's not related to the number of working hours, it's related to the number of hours (or minutes) I managed to keep my focus hard. 

The value of Hard Focus: 
Haruki Murakami in his excellent memori (What I Talk About When I Talk About Running) noted: 
If I’m asked what the next most important quality is for a novelist, that’s easy too: focus the ability to  concentrate all your limited talents on whatever’s critical at the moment. Without that you can’t accomplish anything of value.

The key is to concentrate all your mental abilities on one specific task and foreget about anything else as long as you're working on this one task. This is very important -actually a lot of programming techniques and tools are proven usefeul and highly adopted because it lets you forget about other details and foucs on your specific task.

Luckily enough, Marukami pointed that: "Fortunately [sustaining focus for a long period of time] can be acquired and sharpened through training."

Pomodoro
The pomodoro technique is designed to address this very problem. It's mainly focused on helping you stay focused by working for shorter periods of time, named pomodoros, each is 25 minutes long and during each you're focused on only one task. And while working on this one task you are not allowed to think or worry about anything else. This really helps you cultivate all your energy on attacking one problem. 

Conclusion: 
The number of working hours is not that crucial in CS-related carriers or any other carrier that requires a non-trivial amout on creativity. What matters most is to keep your mind clear, break your problem into smaller problems, and focus on these smaller problems one at a time.

Now I see (and hopefully you dear reader) what every GTD book meant when they loudly screamed in readers' faces "WORK SMART NOT HARD"!

What do you think dear reader? 

Tuesday, March 2, 2010

Routing in ASP.NET 4.0 : A Sneak Peak

Routing

One of the cool features of ASP.NET MVC is the ability to provide clean, extension less, and SEO/user friendly urls. This is accomplished by using the new routing system in ASP.NET.
 
Before ASP.NET 4.0, people used to get these clean urls using a technique called UrlRewriting or UrlRewiring. The technique did get the job done, but unfortunately was somewhat complicated and involved the use of third party components.

Now with ASP.NET 4.0, and with the addition of the new Routing System, we can get clean urls, like those we get with MVC, in Web Forms.

To do this we need to first define our routes, seconde register them in the current RouteTable when the application starts.

For example let's assume that we have a page that should display the details of a certain product given its Id.
The url for this action should look something like "MySite.Com/Products/1". Routes have to be registered in your Application_Start in Global.asax. The code should look something like the following:

void Application_Start(object sender, EventArgs e)
 {
         RegisterRoutes(RouteTable.Routes);

 }

  void RegisterRoutes(RouteCollection routes)
     {
            routes.MapPageRoute(
                "ProductDetails", 
                "Products/{id}", 
                "~/ProductDetails.aspx");
}

I'm leveraging the new MapPageRoute method on the RouteCollection class inside System.Web.Routing.
The first argument of the method is the name of the route, in our case "ProductDetails".
The second parameter is the Url pattern for this route which in this case is the string "Products" followed by
the Id of the product.
The {Id} parameter is the name of the actual parameter added to the RouteData collection. This parameter can then be accessed by the page RouteData property like so:
int id = Convert.ToInt32(RouteData.Values["Id"]);

RouteData is a shortcut property of RequestContext.RouteData. The above statment is equivalent to this one:
int id = Convert.ToInt32(HttpContext.Current.Request.RequestContext.RouteData.Values["Id"]);


Note:
This is a very trivial example. The routing system is pretty powerfull. It can enable you to do a lot of neat stuff with it for example, you can generate urls out of the routing values, you can also add regular expression constraints on your route parameters to differentiate what route matches which request.