using System;
using System.Collections.Generic;

class Person
{
    public String Name { get; set; }
}

class Example
{
    static void Main()
    {
        var people = new List<Person> { 
            new Person { Name = "George Washington" } };

        Console.WriteLine(
            people.Contains(
                new Person { Name = "George Washington" }));
    }
}

If you said “True” then unfortunately you would be incorrect – this program prints “False”. Before I explain why this program prints “False” I would like to make one slight change to this program to make it print “True”.

using System;
using System.Collections.Generic;

struct Person
{
    public String Name { get; set; }
}

class Example
{
    static void Main()
    {
        var people = new List<Person> { 
            new Person { Name = "George Washington" } };

        Console.WriteLine(
            people.Contains(
                new Person { Name = "George Washington" }));
    }
}

Did you spot it?

If you look carefully you will notice that I changed the Person type to be a struct instead of a class. Why would this make a difference? In order to understand let’s take a brief tour of how C# (and the CLR) handle equality.

Whenever you create a type without overriding the Equals method or implementing the IEquatable<T> interface you relinquish control over how two instances of your type will be compared and accept the CLR’s default comparison mechanisms. If your type is a reference type (a class) you will get identity equality and if your type is a value type (a struct) you will get value equality.

Identity equality

Reference types are called reference types because the object itself is stored on the managed heap and you access that object via a reference to that object.

When you compare two instances of a reference type (like the Person type in my first example) the CLR will compare the references to the objects to see if the references point to the same object. Two reference types will only be equal if their reference point to the exact same object on the managed heap. If the references are different the objects are not equal then neither are the objects – even if their fields are identical.

Identity equality asks this question:

Do these two references point to the same object on the managed heap?

Value equality

Value equality is a different process but is actually much simpler to understand. Value equality takes all instance fields of a value type and compares them to the instance fields of a second instance in respective order. I would imagine that value equality works much the way most developers expect all equality checks ought to.

Value equality asks this question:

For each field in these two instances, are all the values equal?

So does this mean that in order to have value equality we must use value types? Of course not! I will soon publish a follow-up article explaining the proper way to do value equality with reference types and also why a boxed value type can never be used for reference equality.

using System;
using System.Net;
using System.IO;
using System.Text;

class Example
{
    static void Main()
    {
        Console.WriteLine(
            getWebPage("http://example.com"));
    }

    static String getWebPage(String url)
    {
        WebRequest request = WebRequest.Create(url);
        WebResponse response = request.GetResponse();
        Stream stream = response.GetResponseStream();
        StreamReader streamReader = new StreamReader(stream);
        return streamReader.ReadToEnd();
    }
}

At first glace there doesn’t appear to be anything wrong at all – the program compiles and runs. This program does exactly what it sets out to do.

So what is the problem? Perhaps this second example will help you see better what was wrong with the first one:

using System;
using System.Net;

class Example
{
    static void Main()
    {
        Console.WriteLine(
            new WebClient().DownloadString("http://example.com"));
    }
}

The problem is now quite apparent: the .NET framework has a method that allows you to retrieve a string response from a URL. If the developer who wrote the first example had known this they would have saved a lot of time and effort by using the framework method that accomplishes the task instead of creating their own.

This is a simple example of an all too common problem:

Many developers don’t know their frameworks.

Why is it important to know your framework? You write less code and spend less time working on algorithms that have already been designed and tested by someone else. Also the person who wrote the framework (let’s face it) is probably a lot smarter than you or me and was able to write a better implementation that we could have.

Finally, you must think about the readability of your code. What is easier to understand, a custom method that the reader must read to continue understanding your program or a framework method that they are most likely already familiar with? Consider the first example and the getWebPage method. Another programmer reading the the Main method of this program would have to read the entire implementation of the getWebPage method to understand what it does. This same programmer would most likely be familiar with the WebClient.DownloadString method from the .NET framework and would instantly understand what was going on and if they didn’t they would be able to consult the documentation of the framework.

So if you don’t already know your framework how do you go about learning it? You need to be constantly pushing yourself to learn new things. Does your IDE offer auto-complete information about the libraries you use? Try turning that off occasionally to see how much you remember. Other times leave it on and explore the APIs of your framework and see what methods are out there that you haven’t used before.

Before you begin designing a solution to a problem, search the internet for other folks who have solved the same problem. These searches will either lead you to framework documentation or code examples that will help you solve problems using existing functionality.

In conclusion it is important to remember that you won’t always get this right and you will re-implement framework functionality by mistake. But if you strive to find reusable components before writing your own you will make this mistake less often.

I really want to get at an ASP.NET control with JavaScript but once the control has rendered, the ID of the control gets mangled to look something like ctl00_Content_foo_bar. How do I go about working with this control in JavaScript since the ID is dynamically generated?

There are many possible solutions to this problem:

1. Hard-code this ID into your JavaScript code.
2. Generate your JavaScript code in your code-behind as a string so that you can embed the ID dynamically.
3. Add a CSS class to the control and use something like jQuery’s CSS selectors to find our control (other JavaScript frameworks have similar methods).
4. Find some way to pass the ID down to the JavaScript by squirreling it away in a hidden input or invisible element.

While these solutions may work they are far from ideal. Here are the problems I see:

1. The practice of hard-coding is brittle and any changes to your ASP.NET code could potentially break your JavaScript code.
2. This solution has potential but still is ugly since you now have to maintain your JavaScript as a string and since the code no longer lives in a separate file, browsers will no longer be able to cache your JavaScript locally.
3. Finding an element by a CSS class sacrifices performance to work (it is much slower than selecting by ID).
4. This final solution has promise as well but requires a lot of plumbing and extra markup to accomplish something that should be simple.

Here is a better solution:

Wrap your ASP.NET control’s markup in a plain HTML element and give that element an ID.

Here is an example:

<div id="fooWrapper">
    <asp:textbox id="foo" runat="server"/>
</div>

Now that you have wrapped your control in an HTML element that is not set to be runat="server", its ID will not be mangled when the page is rendered. This means you can retrieve the textbox by first finding its parent and then finding the next immediate child element of type input.

Here is how I would do it using jQuery:

textBox = $("#fooWrapper input:text");

I truly believe this is the simplest and most straightforward solution to this problem and it will also provide better performance that most other options.

Here is an example:

using System;

class Example
{
    static void Main()
    {
        Console.WriteLine("hello, world" is String);  // True
    }
}

Obviously this is a simple example but I am sure that the reader is capable of extrapolating more practical usages of is. There is an inherent problem with is however that many developers are not aware of:

Under the covers, the is operator uses a cast to make its determination.

Why is this a problem? The reason it it a problem is because the next step most developers take is to cast the instance to the type. This is viewed as a sort of “safe cast” since you know that the instance is of that type. Here is an example of this practice:

using System;

class Dog
{
    public void Speak() { Console.WriteLine("Bark!"); }
}

class Example
{
    static void Main()
    {
        Object obj = new Dog();

        if (obj is Dog)
            ((Dog)obj).Speak();  // Bark!
    }
}

In this example there are actually two separate casts, the is and the explicit cast below it (inside the conditional statement). You shouldn’t cast more then once if you don’t need to do so. Also, the is check does not consider user-defined conversions (such as implicit and explicit cast operators) so is may return false for an instance that could have successfully been casted.

So what should we do instead?

Enter C#’s true safe casting operator: as. The as operator allows you do do an explicit cast on a type while avoiding any InvalidCastExceptions that may occur by assigning null to the variable if the cast fails.

Here is an example of how to use as:

using System;

class Dog
{
    public void Speak() { Console.WriteLine("Bark!"); }
}

class Example
{
    static void Main()
    {
        Object obj = new Dog();

        Dog dog = obj as Dog;
        if (dog != null)
            dog.Speak();
    }
}

This example only contains one cast and also allows you to avoid any exceptions that may occur at execution time.

So, the important thing to remember is that if you feel like you need to use is, most likely you ought to use as.

Note: Be careful that you are not using casting to solve a problem that would be better solved with polymorphism. If you find that you are doing multiple checks for different types, casting, and then calling methods on those types, you should reevaluate your approach to see if a polymorphic solution would be better. Casting is a powerful tool but it can be misapplied.