A Sequel to Wagner’s "Effective C#" in the works

indiana-jones-fedora

Can a sequel be better than the original?  With movies this is usually not the case, though we are all holding our breaths for the new installment in the  Indiana Jones franchise.  Technical books, however, are a different matter.  They have to be updated on a regular basis because the technology changes so rapidly.  My bookshelf is full of titles like Learning JAVA 1.3  and Professional Active Server Pages 2.0 which, to be frank, are currently useless.  Worse, they are heavy and take up a lot of room.  I’ve tried to throw them away, but the trash service refuses to take them due to environmental concerns, and there isn’t a technical books collection center in my area.  In Indiana Jones and the Last Crusade (made before the word "Crusade" got a bad rap) there is a comic scene of a book burning in Berlin, and though I am not in favor of book burnings in general — you’d think we would have learned our lesson after the Library of Alexandria burned down — still, occasionally, I dream of building a bonfire around COM Programming for Dummies and its ilk.

Scott Hanselman recently posted asking about the great technical books of the past ten years, and one of the titles that came up repeatedly is Bill Wagner’s Effective C#: 50 Specific Ways to Improve Your C#.  The book is great for .NET programmers because it goes beyond simply explaining how to write Hello, world! programs, but instead tries to show how one can become a better developer.  The conceit of the book is simple.  For each of his 50 topics, he explains that there are at least two ways to accomplish a given task, and then explains why you should prefer one way to the other.  In the process of going through five or six of these topics, the reader comes to realize that what Bill Wagner is actually doing is explaining what makes for good code, and when both paths are equally good,what makes for elegant code.  This helps the reader to form a certain habit of thinking concerning his own code.  The novice programmer is constantly worried about finding the right way to write code.  The experienced programmer already knows the various right ways to do a given task, and becomes preoccupied with finding the better way.

The way I formulated that last thought is a bit awkward.  I think I could have written it better.  A semicolon is probably in order, and the sentences should be shorter.  Perhaps

The novice programmer is preoccupied with finding the right way to perform a task; the experienced programmer knows that there are various right ways, and is more concerned with finding the most elegant way.

or maybe

The novice is preoccupied with finding the right way to get something done; the expert is aware that in programming there are always many paths, and his objective is to find the most elegant one.

Alas I am no Le Rochefoucauld, but you get the idea.  This is something that prose writers have always considered a part of their craft.  Raymond Queneau once wrote an amazing book that simply takes the same scene on a bus and reformulates it some fifty times.  Perhaps Amazon can pair up Bill Wagner’s Effective C# with Queneau’s Exercises in Style in one of their "…or buy both for only…" deals, since they effectively reinforce the same point in two different genres, to wit: there is no best way to write, but there is always a better way.

If you do get on a Queneau kick, moreover, then I highly recommend this book, a pulp novel about Irish terrorists, which has a remarkably un-PC title, and for which reason I am not printing it here.  I assure you, the contents are better than the title.

The only shortcoming of Bill Wagner’s book is that it was written for C# 1.0, while we are currently at iteration 3.0.  It is still a remarkably useful book that has aged well — but alas, it has aged.  It was with great excitement, then, that I read on Bill’s blog that he is currently working on a title called More Effective C# available for pre-order on Amazon and as a Rough Cut on SafariBooksOnline

The current coy subtitle is (#TBD) Specific Ways to Improve Your C#. To fulfill the promise implicit in the book’s title, More Effective C#, doesn’t the final #TBD number of Specific Ways have to be at least 51?

Using statements with unknown types

I recently came across some interesting code in Juval Löwy’s Programming WCF Services and wanted to share.  It’s simply something I had never run across before:

 

            IMyContract proxy = new MyContractClient();

            using (proxy as IDisposable)

            {

                proxy.MyMethod();

            }

 

The first thing to notice is that the proxy object is instantiated outside of the using block.  I don’t think I’ve ever actually tried this, but it is perfectly permissible (if not recommended).  I used a dissembler to look at the IL this generates, and it is pretty much the same as instantiating the proxy object inside of the using brackets.  The main difference is that in this case, the scope of the proxy object extends beyond the using block.

Within the using brackets, this code casts the proxy object to the IDisposable interface so the Dispose method will be available.  Since a Using Block is basically syntactic sugar for a try-catch-finally structure that calls an object’s Dispose method in the finally block, the equivalent try-catch-finally block would look like this:

 

            IMyContract proxy = new MyContractClient();

            try

            {

                proxy.MyMethod();

            }

            finally

            {

                ((IDisposable)proxy).Dispose();

            }

 

However, Juval’s using statement does one additional thing.  It also checks to see if the proxy object even implements the IDisposable interface.  If it does, then the Dispose method is called on it.  If it does not, then nothing happens in the finally block.  The equivalent full blown code, then, would actually look something like this:

 

            IMyContract proxy = new MyContractClient();

            try

            {

                proxy.MyMethod();

            }

            finally

            {

                IDisposable disposable = proxy as IDisposable;

                if (disposable != null)

                {

                    disposable.Dispose();

                }

 

            }

 

… and we’ve condensed it to this …

 

            IMyContract proxy = new MyContractClient();

            using (proxy as IDisposable)

            {

                proxy.MyMethod();

            }

 

It’s probably not something that will come up too often, but if you have a situation in which you do not know whether an object implements IDisposable or not, but still want to implement a using block for readability and good coding practice, this is how you would go about doing it.  

Besides Juval’s proxy example, I can imagine it coming in handy when dealing with collections in which you don’t necessarily know whether all of the members of the collection implement IDisposable, for instance:

 

            foreach(IDog dog in myDogsCollection)

            {

                using (dog as IDisposable)

                {

                    dog.Bark();

                }

            }

 

It also just looks really cool.  h/t to Bill Ryan for pointing this out to me.