Charles Petzold

Jeff Richter must be some kind of genius. He managed to figure out how to write the one book that every .NET programmer needs to have, and he came up with a totally cool title that essentially says "If you don't know what this means, perhaps you'd be happier shopping in a different section of the bookstore."

CLR via C# is actually the second edition of Applied Microsoft .NET Framework Programming. I read the new book while writing my free on-line book .NET Book Zero, primarily so I made sure I got all the lingo right and didn't make any grotesque boners. I think of .NET Book Zero as the "baby version" of CLR via C#. It doesn't come anywhere close to the depth and detail in Jeff's book, and is certainly no substitute.

What CLR via C# demonstrates most of all is this: No matter how much you think you know .NET, there's probably some weird stuff going on that you've never even thought about. There are some real eye-openers here. For example, did you know that programs written in IL and even some languages (like managed C++) allow throwing exceptions not derived from System.Exception? And that if you're using some DLL class with such code, and your final catch block refers to Exception, prior to .NET 2.0 it did not catch these other exceptions? Neither did I, but there it is on pages 426-427. Fortunately, that's been mostly fixed. (Do you know how? Of course that information is in there as well.)

I particularly enjoy Jeff's sometimes startling opinions on the .NET Framework and C#. For example, on page 119 he recommends that C# programmers use the framework names of basic data types (such as Int32 or Single) rather than the C# keywords (the familiar int and float). Of course, anyone's who's actually searched for an IConvertible method named ToFloat knows the problems with these dual names.

But in terms of opinions about .NET, the real jaw-dropper was in the Properties chapter. After observing that using properties and fields involve the same syntax, and then listing the ways in which they're different in terms of side-effects et. al., Jeff asserts (page 218):

If I had been involved in the design of the .NET Framework and compilers, I would have not offered properties at all; instead, I would have programmers actually implement Getxxx and Setxxx methods as desired. Then, if compilers wanted to offer some special, simplified syntax for calling these methods, so be it. But I'd want the compiler to use syntax that is different from field access syntax so that programmers really understand what they are doing—a method call.

Wow! I really disagree with this one. I think the syntax and naming-conventions of properties has been justified by the ease in which property names are preserved in XML serialization and deserialization, including their use in XAML. Can you imagine how confusing it would be for documentation to list SetFontSize and GetFontSize methods but for XAML to refer to FontSize?

If anything, the confusion between properties and fields should probably be fixed by doing something different with field-access syntax, or restricting fields in some severe way. For example, suppose that fields could only be declared as private, and only accessed from within property definitions. That change would both preserve the lovely and wonderful property-access syntax, and relegate fields to the dark corners of our classes and structures where they belong.