Refer to the project CodePlex page for detailed usage and binary/code download. The library uses the great YUI Compressor library for the minification part.

Hopes it helps!

Luckily, Google’s cache made it possible for me to retrieve the text and posted them again with an adjusted timestamp. As for the comments, since there were many of them and yet not all of them could be found in Google’s cache, I had to leave them for now. Therefore, you won’t see any comments dated from 1/9/2009 to around June 2009 (when the migration occurred). My sincere apologies to those comments are lost due to this incidence. I myself feel very very bad about it. I will work with the host provider in a last attempt to find way to recover the comments. If that doesn’t turn out right, I will find a new provider. And I will surely backup my blog frequently in the future.

Now, young developers, before you start throwing away all the books about design patterns, agile, OO principles etc., let me tell you one thing: if Jeff Atwood is a better developer at all today, it’s because he has learned from the rules preached by more knowledgeable people. Don’t believe? Read this. There you go, Jeff Atwood as a fan of Code Complete, a 900-page book full of coding rules, was so much interested in the book that he even named his blog after one of the book’s symbol. He just seems to forget about where he came from when he wrote:

While I do believe every software development team should endeavor to follow the instructions on the paint can, there’s a limit to what you can fit on a paint can. It’s the most basic, most critical information you need to proceed and not make a giant mess of the process. As brief as the instructions on a paint can are, they do represent the upper limit of what most people will realistically read, comprehend, and derive immediate benefit from.

It’s normal for a very experienced developer to rely mostly on his judgment instead of a set of rules and principles to do thing. But it’s just uncool for such an experienced developer to advise the newbies to do the same thing, i.e. they’d better use their judgment first before resorting to the distilled and valuable knowledge taught by others.

…I’ve found less and less use for rules in my career. Not because I’m a self-made genius who plays by my own rules, mind you, but because I value the skills, experience, and judgment of my team far more than any static set of rules… Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substute for thinking critically about your work.

The thing is people are not born making good judgment. And one of the best ways to sharpen one’s judgment is to learn from the knowledge of those people who have made good judgment. Only after one has practiced these teachings long enough, making a lot of right and wrong decisions based on these teachings, one will for the first time, really understand about them and don’t have to think about them any longer as they have become part of one’s instinct. That should be the thing experienced developers teach junior developers, not this:

The types of developers who could benefit from SOLID a) aren’t thoughtful enough about their work to care and b) won’t read much of anything

Don’t get me wrong, I respect many of Jeff’s opinions, but I think he should feel more responsible for his influence on those developers who are new to the industry and seek for advices from his writings. Obviously no one man is perfect and Jeff, like any other, doesn’t necessarily always have great things to say. But at least he should acknowledge that he’s wrong when he’s wrong.

Appendum 2/14
On the contrary to what I think Jeff Atwood should do in the previous paragraph given the large amount of thoughtful comments from many of his readers, he seems to dig himself deeper into the hole with his follow-up post.

• Built for MS Validation Application Block. (Emad Ibrahim’s library targets Castle’s validation framework. Check out his library if you need this feature.)
• Allow users to specify the properties to be included in a server-side validation. This is useful in situation in which you use part of the model in some pages (e.g. Change Password page only uses the Password field of the User entity).
• Allow users to tell the client-side code generator to generate script to ignore missing DOM elements. This feature goes nicely with the above feature. The generator could have been implemented to receive a list of properties to generate client script for but I have not made up my mind yet whether this is a better approach or not.
• Allow users to specify whether they want the validation initialization code to be generated or not. This is particular useful if you want to customize the validation initialization code differently for different pages.

How does it work?
The idea of the library is that one should be able to decorate an entity object with some validation attributes and then have that entity validated at both the server-side and client-side with the minimum amount of code. Let’s say you have a User entity in your application, you can annotate it as follows:

public class User
{
     [NotNullOrEmptyValidator(MessageTemplate = "Name is required")]
     [StringLengthValidator(6, 20, MessageTemplate = "Name must be between {3} and {5}")]
     public string Name { get; set; }

     [NotNullOrEmptyValidator(MessageTemplate = "Email is required")]
     [EmailValidator(MessageTemplate = "Invalid email address")]
     public string Email { get; set; }

     [NotNullOrEmptyValidator(MessageTemplate = "Location is required")]
     public string Location { get; set; }

     [NotNullOrEmptyValidator(MessageTemplate = "Password is required")]
     [StringLengthValidator(6, 50, MessageTemplate = "Password must be between {3} and {5}")]
     public string Password { get; set; }
}

Now, whenever this entity is populated with form posted values, you can perform server-side validation by invoking the Validate() extension method on the entity. Let’s do that in the action method.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult EditUser([Bind(Prefix="")]User user)
{
     try
     {
          user.Validate<User>();
     }
     catch (EntityValidationException ex)
     {
          ViewData.ModelState.PopulateWithErrors(ex);
     }
     return View();
}

The above code will perform validation on the entity given its validation attributes. If there’s any validation error, an EntityValidationException object is thrown and you can use it the populate the model state with error messages. The method PopulateWithErrors is another extension method provided by the library.

If you want to limit the properties to be validated (e.g. in a password change scenario), you can pass an array of property names into the Validate() method.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult ChangePassword([Bind(Prefix="")]User user)
{
     try
     {
          // Only validate the password property
          user.Validate<User>(new[] {"password"});
     }
     catch (EntityValidationException ex)
     {
          ViewData.ModelState.PopulateWithErrors(ex);
     }
     return View();
}

I could have added a custom model binder to the library so that validation happens at the model binding phase but I think that’s not a flexible approach since in many cases we would want to perform validation in the service layer instead so that the validation takes place consistently for any client of the service.

Let’s see the result of the server-side validation:

Okay, let’s move to client-side validation. The trick behind the client-side validation is that the view will invokes the HtmlHelper’s ClientSideValidation() extension method which will retrieve all validation attributes of the specified entity type (e.g. User) and generate equivalent client-side validation script for them.

Currently, while you can apply as many validation attributes to an entity as you like and the server-side validation will work perfectly fine, only a couple of validation rules are supported by the client-side code generator, namely required field validation, string length validation, and email validation. These3 rules are sufficient for my current need and I will add more on a needed basis (or you can download the code and implement more rules yourself.)

There are a couple of overloads of the ClientSideValidation() method:

// Generates validation script for the User type
Html.ClientSideValidation<User>();

// Generates validation script for the User type, including the code to initialize form validation
Html.ClientSideValidation<User>(string formName);

// Generates validation script for the User type and adds necessary code to avoid JavaScript error if one or
// more properties in the User type do not match with any DOM element.
Html.ClientSideValidation<User>(bool ignoreMissingElements);

// See the above 2 overloads
Html.ClientSideValidation<User>(string formName, bool ignoreMissingElements);

For example, the generated code for an invocation of the second overload will result in the following code:

<script language="JavaScript"><!--
$().ready(function() {

$("#edit-user-form").validate();
$("#name").rules("add", {
	minlength : "6", maxlength : "20",
	required : true,
	messages: {
		minlength : "Name must be between 6 and 20", maxlength : "Name must be between 6 and 20",
		required : "Name is required"

	}
});

$("#email").rules("add", {
	required : true,
	email : true,
	messages: {
		required : "Email is required",
		email : "Invalid email address"
	}
});

$("#location").rules("add", {
	required : true,
	messages: {
		required : "Location is required"

	}
});

$("#password").rules("add", {
	minlength : "6", maxlength : "50",
	required : true,
	messages: {
		minlength : "Password must be between 6 and 50", maxlength : "Password must be between 6 and 50",
		required : "Password is required"
	}
});

});
--></script>

That’s it, you don’t need to write a single line of JavaScript to have this nice client-side validation:

How can I download and use it?
The library is hosted at CodePlex. I have built it with ASP.NET MVC Beta, Enterprise Library 4.1, jQuery 1.2, and jQuery validation plug-in 1.5. You might need to make a couple of changes if you want it to work with a different version of those libraries. Any bug, please post on the project page instead of posting here. Thanks & hope you’ll find the library useful.

• First and most common mistakes: the CV lists too many skills. In fact, I’ve seen many CVs with roughly a dozen lines mentioning about many dozens of technologies and tools. In many cases as the on-site interviews revealed, these developers just possessed superficial or absolutely no knowledge about the things they listed. One can only go so far (to the on-site interview) being untruthful. On the other hand, even if these developers really know about these things, among the too many things they list, I can hardly find the ones that should really stand out (i.e. the things that the candidates have expertise in.) Now, there are those of you who really have extensive set of skills under your belt and want to list them all, it’s still better if you can highlight the top skills that you master so that they can stand out from the rest. Most of the time, employers don’t care about the skills you are not really good at. Think about it, would I hire a top .NET developer to write Java code just because the guy happens to know a bit about Java?
• Some candidates describe what they were supposed to do instead of what they actually did in their previous positions. If one implemented the security module of a software using Spring Security or used Struts 2.0 to implement a web module of another software then I would want to know about that. On the other hand, I don’t want to read a some general job description stating the obvious and of little interest (to me) such as “designed and implemented the application”, “worked with QA to resolve defects”, and “participated in code review” etc. (Guess what, if you’re not doing these things, you are not developers.) On the other hand, some candidates went so far quoting text from the job description while they have not actually carried out such responsibilities and that has resulted in quite a couple of embarrassing on-site interviews. Be very specific about the things that you did is the key to avoid this mistake.
• Mention too much about the clients and products. As a matter of fact, I’ve seen some CVs in which every project is accompanied with a lengthy paragraph describing the product and its client. Much of this information is pulled out of the marketing information provided in the client’s or product’s website. Keep this in mind: most employers don’t care about the vision of your client organization and the greatness of the product. For the software that you built, only 2 things should be mentioned in the CV: what problem the software solves and what technologies it is built with. Anything other than that is noise and should go away. For the client, the name and a link to their website are more than enough. For the really rare case that I want to learn more about the client, I will find more information through the provided link (or Google, for heaven’s sake).
• Some CVs mention too trivial projects. Don’t get me wrong, it’s good to demonstrate how much passionate you are about this software engineering by listing things like, say, personal projects but there’s no point mentioning some trivial toy or university projects in your CVs. Think about it, how much value the employer gains knowing that a developer can code a Tic Tac Toe game or a shopping cart? Absolutely nothing unless you expect us to say to ourselves “Look, that guy is really cool – he can code Tic Tac Toe.” Save the space for more valuable things instead. If there’s no such thing, better save us some reading time by removing them from the CV.
• Spelling and grammar mistakes in CVs. I am constantly surprised that many developers don’t even care to do a quick check to make sure no grammatical and spelling mistakes in their CVs. After all, it only takes a few minutes for this check to be done with any word processing software. Without doing this, one risks leaving a bad impression to the recruiter; the impression that the author of this CV is either lazy, doesn’t care about getting the job, about doing the right things, or about going the last mile to get the work done. That might be a harsh conclusion one can come up with given just a few spelling mistakes, but given the sheer amount of CVs recruiters have to screen for any particular position, they are not supposed to be very patient and tolerant of poorly written ones.
• A bonus tip: don’t be afraid to list your certifications if you have any. This is actually not a common mistake, but since there is a rising number of people who suggest that developers should not include certifications in their CVs, I think it’s worth setting an alarm. Anyone who have under their belt a few certifications know that it’s not the papers themselves that have a lot of value but the actual studying process that one usually gets through to get those papers is valuable. Plus, if one spends the time that would otherwise be spent on vacation or gaming to study and achieve some certifications relevant to her work, it means that she cares, if is not passionate, about her job. And that is never a bad thing. Finally, with all things being equal, some companies would prefer to hire developers with one or more certifications than others because that would help with the partnership process with vendors like, say, Microsoft (like it or not, there are obvious benefits to become partner of the big vendors).

That’s it, the top CV mistakes. Am I missing anything?

Indeed, when you are in a position to receive projects from clients and responsible for hiring people to accomplish those projects, you’ll quickly realize one thing: there are just not enough talented or passionate developers, much less those who are both passionate and talented. Truth be told, I was extremely selective in my hiring to the extent that I was infamously known among the HR department as a “candidate eliminator”. And yet, I think less than 5% of those I selected into onsite interview met both criteria. That said, if I had rigidly maintained my rules of placing passion and talent before any other, I would never have found enough people for all the projects. In such situation, there are 2 things one can do: give up and reject the client projects for not being able to find enough members to staff in, or staff the best you can and find ways of accomplishing the projects. Now, nobody in his or her right mind would go with the first option.

After spending more than a year working with impassionate and not talented people, I have come to realize that a team which has such developers can still deliver good result. Now, among those people, I have yet to find a person who is passionate but has poor programming skills, but the remaining categories (impassionate but talented and impassionate and not talented) turned out to add value to the team in one way or another. Specifically, I realized that impassionate developer can still be good developers. These developers would rather go home early and spend time taking care of their family or pursuing their real passions. They never write any blog or participate in any open source projects nor do they have any plan to do so. And they only learn things as they are needed instead of browsing through latest books and blogs to learn about the trendy things. But when they do something, they do it with utmost attention and most importantly, they write good code. That should not be a surprise. You just need to realize that good developers are, well, good developers regardless of whether they spent 8 or 16 hours per day programming. (Although the one spending more time may learn more.) As a matter of fact, two developers in one of the projects I worked on were not passionate about software development at all. They just realize that programming is something they are good at, so they do it to get the money to spend on the things they really love. One guy’s passion is photography, but he is smart enough to know that he can’t make as much money being a photographer. He loves it, but he simply has no talent for it.

I’ve been talking about good developers who are not passionate. How about those who are both impassionate and have bad programming skills? I worked with them too, and I have to say: such people are NNPPs mostly because they are mismanaged. A good manager will recognize the strengths and weaknesses of their members to put them into the right position. Before you laugh at the idea, think about all the work that need to be done for the projects to be successful. Are you sure that all of such work require really smart developers to do? Do you need good developers to maintain the project’s build scripts? Or setup a build system? Or evaluate a tool? How about writing project documentations? Or migrate one source control system to another? Simple bugs of well understood components (or even more complex bugs but have the new code reviewed by good developers, but that’s another story)? The point is, in just about any software development project, there are always some work which smart and passionate people hesitate to do (and may not do it well if they have to do it) but enthusiastically accepted by others. Let the latter do such work, they are neither passionate nor smart but they work for the pay in order to do things they really love. Therefore, they are willing to do so and even feel happy for not being asked to do more than what they are capable of doing. And you, the passionate and smart developer, can be happy too. The right-person-for-the-right-job is the name of the game.

Having said all these, sometimes some people just don’t fit to your project, then you have to let them go. But the point remains the same, things would be much easier if we can find all the top guns and put them into the team. But we simply can’t. Sometimes, we have to live with what we get and do the best about it. Just face it. And happy programming.

For example, if I want to sketch a grid populated with some existing data all I need to do is dragging the grid component out of the toolbar and fill in some CSV-formatted text. (Anyone experiencing drawing data-grids with Visio will know the process is not that straight-forward.) Or if I want to create a tag cloud, I just simply enter some words and Balsamiq will weight the words randomly and display them in a nice tag cloud picture. For more complex components like tree or menu, a wiki-like syntax is available to fill in the data and decorate the output (e.g. menu item separator, checked menu item etc.) This simple process of entering some plain text repeats for all kind of GUI components which need input data.

Although I am happy with what Balsamiq has to offer, I wish the software has features to allow users to draw arbitrary shapes and add custom images into the mockups. For now, users are limited to whatever GUI components and icon images provided out of the box. Regardless, I think these requirements not necessary for a majority of GUI mockups and for most of the rest I think I can resort to my modest photo-editing skills .

Below is a sample mockup created with Balsamiq. See more here.

The .NET framework 4.0 CTP has just been released and I think it’s a good time to explore the new features of C# 4.0. In this post, I will introduce about the following features: dynamic lookup, generics covariance and contravariance support, optional and named parameters.

1. Dynamic Lookup
If var in C# 3.0 brings about type inference for local variables with the purpose of saving a couple of key strokes, dynamic lookup adds much more to the dynamicity of the C# language. When you declare a variable with dynamic, all of its method invocations or member accesses will be resolved at runtime. For example, let’s look at the following code

public static void Main() {
    dynamic obj = “I’m statically System.String”;
    obj.NotExistingMethod(“param”);
}

In the code, we create a string object and instead of assigning it to a variable of type string, we assign it to a variable declared as dynamic. This basically instructs the compiler to not to attempt to resolve any method call or member access of the declared variable. Instead, all these resolutions will happen at runtime. That being done, the next line in which we invoke a non-existing method with an arbitrary parameter will compile just fine into CIL. At runtime, when the method call is resolved and the runtime finds that there’s no such method in the runtime type (which is a System.String), an exception is thrown. That being said, if we use a valid method then there would be no exception and the code will run fine till completion. For example:

    dynamic obj = “I’m statically System.String”;
    Console.WriteLine(obj.ToLower());

Not only that we can declare a variable as dynamic, we can also declare methods’ arguments to be so. For example:

    private static void PrintID(dynamic obj) {
        Console.WriteLine(obj.ID);
    }

    public static void Main() {
        var person = new {ID = 111, Name = "Buu"};
        PrintID(person);

        var account = new {ID = 101, Bank = "Some Bank"};
        PrintID(account);
    }

We basically create two anonymous types, for the sake of convenience, both having a property called ID and then instantiate objects out of these types. We then pass each of these two objects to the method PrintID which accepts a dynamic object and print out the ID property. The code will print out “111” and “101” respectively. And yes, we’ve just seen duck typing in action. In C#.

That example also shows an interesting usage of dynamic in regarding to anonymous types. Now, we can pass objects of anonymous types out of their declaration scope (e.g. the method) and still be able to invoke their methods or access to their members without resorting to verbose reflection code. (And in fact, whenever you see any piece of reflection code in your application and regardless of the code’s purpose, there might be an opportunity to replace it with dynamic lookup to make the code more readable.)

We are not just limited to make statically typed .NET objects become dynamic, we can use this dynamic lookup feature to conveniently interact with “actual” dynamic objects available through the Dynamic Language Runtime (DLR) included in .NET framework 4.0. In fact, one can implement such dynamic objects in C# by implementing the System.Scripting.Actions.IDynamicObject interface, which is also part of the DLR. Regardless of the actual receiver of dynamic dispatch, the usage of dynamic lookup is exactly the same from the caller’s perspective.

Some of you might wonder what code the compiler generates and whether there is any change to the CLR to support dynamic lookup or not. To answer that question, let’s look at the CIL generated from the very first code fragment of this post. (Click on the image to see the full size.)

The generated CIL is pretty verbose but a skim through it reveals two important things. Firstly, our “dynamic variable” turns out to be a plain old CLR System.Object instance. And secondly, there’s no new CIL directive or opcode to support dynamic lookup. Instead, dynamic resolution and invocation is completely handled by framework code. In fact, the above CIL is equivalent to the following C# code, but now without the dynamic keyword.

    object obj = "I'm statically System.String";
    var payload = new CSharpCallPayload(
        RuntimeBinder.GetInstance(),
        false, false, "NotExistingMethod",
        typeof(object), null);
    var callSite = CallSite<Action<CallSite, object, string>>.Create(payLoad);
    Action<CallSite, object, string> action = callSite.Target;
    action.Invoke(callSite, obj, "param");

(In fact, I simplified the code a bit so that it can fit in one method, the actual CIL generated does have a check at IL_000c which basically looks at the callSite static field of a nested class, which is generated automatically by the compiler, to see if it’s null or not before going ahead and initializing it. In order words, the callSite is cached for subsequent invocations of the same method.)

So there’s really no magic behind the dynamic keyword. What the compiler basically does is generating some payload containing the information about the invocation so that it can be made at runtime. If there’s any magic at all, it would be in the static method CallSite.Create() which uses reflection to invoke the NotExistingMethod on the given object if it’s not an instance of IDynamicObject.

Now, we know that a “dynamic object” is actually a plain old object; it should explain why method can accept dynamic parameters. It should also be of no surprise to know that dynamic lookup can also be applied to return value of an instance/static method or an instance/static field. After all, unlike the var keyword which requires the compiler to infer the exact type at compile time, the compiler in dynamic lookup scenarios can simply pick System.Object as the type.


2. Generics Covariance and Contravariance
In previous versions of C#, generic types are invariant. That is, for any two types GenericType<T> and GenericType<K>, in which T is a subclass of K or K is a subclass of T, GenericType<T> and GenericType<K> have no inheritance relationship whatsoever to each other. On the other hand, if T is a subclass of K and if C# supports covariance, GenericType<T> is also a subclass of GenericType<K> or if C# supports contravariance, GenericType<T> is a superclass of GenericType<K>.

To understand why pre-4.0 C# disallows covariance and contravariance, let’s look at some code

    var strList = new List<string>();
    List<object> objList = strList; // compile-error, with cast or not

If the code in line 2, it can be error-prone. Consider what we can write after line 2 assuming it is allowed:

    // BOOM: we're adding an arbitrary AnyObject to what, at runtime, is a list of strings
    objList.add(new AnyObject());

On the other hand, if C# supported contravariance, we could have written the following problematic code:

    var objList = new List<object>;
    objList.add(3);
    objList.add(new AnyObject());
    List<string> strList = objList; 

    // BOOM: we're getting an arbitrary object thinking it’s a string
    string element = strList.get(0);

Due to this invariant restriction, although for the good purpose, we can’t easily reuse variables and methods to respectively get assigned to or accepts various generic types. It’s somewhat unfortunately because the key thing to realize that covariance is fine as long as GenericType<T> does not have any method or member accepting arguments of type T (e.g. if we can’t add a bunch of objects into the objList, which is indeed an instance of List<string>, we’ll be safe). Besides, contravariance is just as safe if T does not appear in any return value from a member or method (e.g., if we can’t get out any string from strList, which is indeed an instance of List<object>, we’ll be safe).

Fortunately, C# 4.0 provides us an option: if a generics interface or generics delegate which has a reference type T as its type parameter and does not have any method or member that take in a parameter of type T, we can declare it to be covariant on T. On the other hand, if that interface or delegate does not have any method or member that returning T, we can declare it be contravariant on T. (Notice the emphases, only interfaces and delegates have covariance and contravariance support and the type parameter must be a reference type. On the other hand, C# arrays have been supporting covariance from the very beginning.)

Let’s look at an example. We have a Generator delegate which basically returns random instances of object of certain type (e.g. string). Its declaration is as follows:

    delegate T Generator<out T>();

Because this delegate does not take in any T as its argument, we can safely make it covariant on T. And indeed, that compiler will allow us to do so by adding the modifier out before the type parameter. However, if this delegate is declared as, say delegate T Generator<out T>(T seed) then the compiler will complain since it’s no longer safe for covariance. Now, let’s look at the usage:

    Generator<string> strGen = new Generator<string>(StringGenerator);

    // Below line is compiled now because Generator<string> is
    // subclass of Generator<object> under covariant rule
    Generator<object> objGen = strGen; 

    // Downcast is also allowed for the same reason
    strGen = (Generator<String>)objGen; 

    ...

    private string StringGenerator()
    {
        return "I'm a random string";
    }

With contravariance, you need to use the in keyword. Let’s look at an example making use of both contravariance and covariance:

    delegate K Converter<in T, out K>(T param);

This converter takes an object of type T and converts it to an object of type K (e.g. convert String to Object). Since it does not take in any K, it can safely be declared to be covariant on K. Similarly, since it exposes no T, it can safely declare to be contravariant on T. Its usage is as follows:

    var converter = new Converter<object, string>( ConvertImpl);
    Converter<string, object> string2ObjectConverter = converter;
    object result = string2ObjectConverter("A"); 

    ...

    private string ConvertImpl(object o) {
        return o.ToString();
    }

Note that although the above examples show how to declare covariance and contravariance for delegate types, it’s not different to do so with interfaces.

Before we finish with covariance and contravariance, let’s look at what code the compiler generates. After all, we know that the compiler must encode something to the CIL to denote covariant and/or contravariant generics types so that they can be consumed properly by client code. And this is what the definitions of our Generator and Converter delegates viewed from ildasm.

Do you notice anything? Those little minus and addition signs are used to denote contravariance and covariance respectively. And interesting enough, it turns out that the CLR has been supporting such CIL since the introduction of generics in .NET 2.0. Therefore, it’s possible to write CIL using covariance and contravariance under .NET 2.0+. Only by now that it’s possible to do so using C#.

A final thought about this feature, while this is a good enhancement to the language, I like the generics covariance/contravariance implementation, enabled via wildcards, in Java better for its flexibility. Anyway, let’s just be happy with it for now, we can’t have everything.


3. Optional and Named Parameters
The last two features of C# 4.0 that we’ll discuss about are optional parameters and named parameters. These features have been with VB.NET since forever and I’m glad they are finally implemented in C#.

With optional parameters, we can provide default values for methods’ and constructors’ parameters. That way, we don’t have to write a bunch of overloaded methods and constructors. For example, we can define a constructor like this:

    public Cart(int id, String name = “default cart”, double amount = 0d) {…}

Now, you can invoke this constructor with any of these calls:

   new Cart(1);
   new Cart(1, “my cart”);
   new Cart(1, “my cart”, 105.5);

How exactly does C# implement this feature? If we look at the CIL generated for this code, we’ll see there’s no magic at all. Basically the default values will be injected to the call site so that the method invocation happens normally. Here’s the CIL generated by the compiler:

Some might think that the compiler gets the default values in the source code to inject into the caller’s code. However, that will not work if a method with optional parameters is published as a library. In that case, there’s no way the compiler can get the default values to inject to the code of the library’s client. Therefore, what the compiler actually does is to encode the default parameters right into the method itself. This is what the CIL for Cart’s constructor:

Notice the .param directive which basically tells the compiler about the default values for the optional parameters. These parameters are also annotated by the [opt] attribute.

While being a great feature, there’s a caveat when using optional parameters: since the compiler inlines the default values at the caller site, change to default values at the library site won’t be reflected unless the caller is recompiled. In order words, you should consider default values of parameters as part of the published API of a method and you’d better make them right the first time.

Now, let’s say we want to call the Cart’s constructor with the ID and amount specified but not the name, how would we do that?

To avoid ambiguity (for example when two optional parameters are both strings), C# won’t allow us to simply skip a parameter like this:

    new Cart(1, 15.5d); // compile-error

An approach C# could take is to allow this syntax:

    new Cart(1, , 15.5d);

However, this looks terrible enough with just one missing parameter, much less more of them. (How do you like to read this code MethodWithManyFields(,,,15,,”param”,,)?)

For this particular situation, named parameters are excellent solution:

   new Cart(1, amount: 15.5d);

This is not the only use of named parameters though. A very important purpose of named parameters is to enhance the readability of code. Let’s say you have a class having a bunch of fields that are to be initialized in a constructor. Without name parameters, a constructor of such class will look very ugly and hard to understand without resorting to the documentation, source code, or Intellisense.

One approach is to create a builder to create instance of such class. For example:

   new BigClass.Builder().attr1(“value”).attr2(“value”)...attrN(“value”);

This will make the code more explicit about what values are to be assigned to what fields. However, the drawback is that we need to implement a builder class, which is quite a tedious task if we have to repeat that for many classes in our application.

With C# 3.0, it’s not that bad because we can use object initializer to do something like this:

    new BigClass {Attr1 = “value”, Attr2 = “value”, …, AttrN = “value”}

This looks good, but we have to define all the necessary properties for it to work, which is also a tedious thing to do if we don’t really need properties for the class or if the class itself is immutable.

With named parameters, we have a very nice solution without having to write any builder or property if we don’t want to. (Note the semicolon after the field name.)

    new BigClass{attr1: “value”, attr2: “value”, …, attrN: “value”);

    // The below does the same thing
    new BigClass{attrN: “value”, attr1: “value”, …, attr2: “value”);

Regarding the implementation of this at the CIL level, the compiler is smart enough to infer the correct argument order and simply perform a plain old method invocation.

That’s it. The key features of C# 4.0. I am personally glad that C# has come to support these. Some people said that C# has become so complex and started losing its original beauty. While I can understand that view, I think the situation is not that bad. While it’s obvious that C# has more and more constructs to supports functional and dynamic programming, the statically typed nature and the old constructs of the language are still there and no developer is forced to use the new features if they don’t need to. On the other hand, these features bring more options for those who need them and I’d rather have more options than to be handcuffed.

• The nothing-but-nails architects. These architects have hammer and thus they see everything as nails. That said, these people are very eagle to apply overkill technologies to solve even the simplest problems. If the software has web front-end, then a MVC web framework must be used. If it has to integrate with some back-end system, then an Enterprise Service Bus implementation must be deployed. Business logic? We need Enterprise Java Bean, baby. If there are 100 concurrent users, then the system should be hosted in a farm environment with 2 web servers, 2 application servers and 1 database server. And architecture design won’t stop until these architects have put all 23 GoF patterns and one dozen of enterprise architectural patterns which they just learn from a book into their Visio diagrams.
• The no-news-is-good-news architects. These architects are afraid of new things, those they often insist to be “unproven” and “risky”. Some of these architects are of same group as the nothing-but-nail guys, i.e. they are so proud of their bag of tricks that they feel no other technologies are relevant and all problems are the same. The others are way behind the technological trends that they feel threatened by new technologies and tools. The arguments these architects often use to turn down new ideas include “it will never work”, “this is not practical”, “we already has proven methods, why bother such risky solution?”, or even the discussion-stopping message “I have solved this problem before, I know what works and what do not.” I remember an occasion in which I observed a senior architect criticized heavily the design of another architect who “dared” to suggest the use of Amazon’s SimpleDB as the storage engine for their new web application. Arguments used by the former include “database over HTTP is simply unacceptable”, “we don’t need those thousands of servers in Amazon’s farm”, and “you are bringing extra risk for us by introducing another node of security”. The poor latter architect, he did not know he was suggesting something which was radically new to the mind of the former.
• The do-as-I-said architects. Unlike the no-news-is-good-news group which bashes against new ideas, this group turns down whatever ideas not coming from them. This type may not necessarily feel threatened by new things, they just feel like their ability is being challenged by ideas they did not think of from the first place. If they think using Open ESB should be used, then any suggestion about BizTalk, or a home-grown integration solution that does just the job well will be turned down. Even if they do think the latter two are better ideas. Similarly, they will turn down any “RESTful” ideas because it’s WS-* that they propose in the first place even if they understand that the REST alternative may save them bunch of implementation efforts. Just do as they said and all is good.
• The silver-bullet-obsession architects. This group stands on opposite end from the no-news-is-good-news group: they are crazy about new things. They are so interested in fads and buzzwords that they include these in any presentation they make and any design solution they propose. To these architects, it’s just cool to talk about and use new things while completely dismissing the relevancy of such things to the problem at hand. EJB? So old-fashioned, let’s use RoR. Ajax? Forget about it, RIA is the future. RIA by Flex? Silverlight with managed code is the key. ORM is the past, it should be LINQ-2-SQL all the way down, baby. And they keep spending their career looking for more silver bullets.
• The UML-only architects. If you have read my essay, The Code is the Design, you should be able to guess how bad I feel about architects who think coding is only for the wimps. Indeed, there are architects who think that if they have to write the code then there’s little distinction between them and the plain old poor developers. They think that the role is to direct, i.e. draw some diagrams and handle them out to the coders who will “realize” the design. They argue that coding is just a simple step if the design is done right. Some may go as far as stating that they don’t even need to know how to code in a language or understand the ins-and-outs of a technology before architecting a solution using those language and technology. For example I met an architect who admitted that he had not coded any single line of Java code but thought that he would do fine when architecting enterprise JEE applications. “As long as I have good Java coders to implement my design,” he concluded. A joke? Not at all. True story!

There, we have seen the 5 groups of architects who have somewhat been successfully in ruining the software architect role in the eyes of other people. It’s high time they threw away their arrogance to not look down on others’ opinions, got pass their boosterism to use the most appropriate tools for the problem at hand, and acknowledged their ignorance by continuously learning and keeping up with technological trends. And last but not least, it’s high time they started writing code again… And if the software industry has any luck, 5 or 10 years from now some developers may come across this post and think I was joking.

Unlike others, I don’t write unit test for my code. I hope my code will work right because I’m so good at coding. Even in the rare cases when it doesn’t, the QA team should be able to catch the defects easily and I will immediately know what happen to make necessary fixes. I hope I will never have to touch most of the already written code again and if I don’t have to revisit it, what would unit tests help anyway?

Unlike others, I don’t check in compilable code into the source control system very often. Instead, I code it straight for several days (or weeks) until finishing my module before checking everything in. I hope my code will not break any code of others and I hope others’ code won’t cause funny behavior in mine. Besides, my colleagues should follow the architecture design so carefully that there are no integration defects between their components and mine.

I love coding and I’m different from others. I am superior and productive. I am a hope-driven developer…