Jon Skeet: Coding Blog : Book reviews, Books, C#

Book Review: Effective C# (2nd edition) by Bill Wagner

skeet — Sat, 25 Sep 2010 07:09:24 GMT

Resources:

Disclaimer

Just in case you're unaware, I'm the author of another C# book, C# in Depth. Although Effective C# is somewhat different to my book, they certainly share a target audience. To that extent, Bill and I are competitors. I try hard to stay unbiased in reviews, but it's probably impossible. Bear this in mind while reading. I should also note that I didn't buy my copy of Effective C#; it was kindly sent to me by Pearson, for the purpose of reviewing.

Content and target audience

Effective C# is a style guide for C# developers - but not at the low level of "put your braces here, use PascalCase for method names;" instead, it's at the design level. As far as I can tell, the aim isn't to be complete, just the most important aspects of style. (Hey, otherwise there wouldn't be any need for More Effective C#, right?) There are 50 mostly-self-contained items, totalling about 300 pages to digest - which is a nice size of book, in my opinion. It's not daunting, and the items can definitely be bitten off one at a time.

Looking down the table of contents, the items are divided into six categories: "C# language idioms", ".NET resource management", "Expressing Designs in C#", "Working with the Framework", "Dynamic Programming in C#", and "Miscellaneous". Broadly speaking these contain the sorts of thing you'd expect - although it's worth pointing out that a significant chunk of "Working with the Framework" is given over to Parallel Extensions, which may not be obvious from the title. (It's a really good source of information on PFX, by the way.)

This is not a tutorial on C#. If you don't know C# reasonably well already (including generics, lambda expressions and so on) you should read another book first, and then come back to Effective C# in order to get the most out of it.

Comment from Bill: generics and lambda expressions (and LINQ) are covered in some detail in More Effective C#. It's a bit strange that as of the 2nd edition, Effective C# covers a newer version of the language than More Effective C#. I tried hard to make sure neither book expects a reader to have read the other, but the organization of both books as a whole does show the hazards of hitting a moving target.

That's not to say that there's no explanation of C# - for example, Bill goes into a few details about the "dynamic" type from C# 4, as well as overloading and how optional parameters work. But these are meant to just cover some poorly-understood (or very new) aspects of the language, rather than teaching you from the beginning. The balance here feels just right to me - I believe most professional C# developers will learn details of C# they weren't aware of before, but won't be confused by the basics that Bill left out.

Accuracy, opinion and explanation

My copy of Effective C# has plenty of ink annotations now. They broadly fall into five categories:

"Ooh, I'd never thought of that" - aspects of C# which were genuinely new to me
"Hell, yes!" - things I agree with 100%, and which will help developers a lot
"Um, I disagree" - points where Bill and I would go probably different routes, presumably due to different experiences and having worked in different contexts. (It's possible that when put in the same context, we'd do the same thing, of course.)
"No, that's technically incorrect" - a few areas which are outright wrong, or were correct for previous versions of the framework/CLR, but aren't correct now
"That's not what that term means" (or "that's not the right term for the concept you're trying to get across") - it should come as no surprise to regular readers that I'm a bit of a pedant when it comes to terminology

The majority of my annotations are of the third category - disagreements. That's not because I disagree with most of the book; it's just that the second category is reserved for vehement agreement. I haven't bothered to note every sentence that I'm just fine with.

The good news is that in areas where we disagree, Bill does an admirable job of stating his case. I disagree with some of his arguments - or I can give counter-examples, or merely place different value on some of the pros and cons - but the important thing is that the reasoning is there. If it doesn't apply to your context, evaluate the advice accordingly.

It's entirely reasonable for there to be quite a bit of disagreement, as much of the book is opinion. It's obviously founded in a great deal of experience (and I should note that Bill has spent a lot more time as a professional C# developer than I have), but it's still opinion. I rather wish that the book was a wiki, so that these items could be debated, amended etc, as per my dream book - I think that would make it even more valuable.

There are relatively few absolutely incorrect statements, and even on the terminology front it's usually two things which have bugged me repeatedly. Bill uses "implicit properties" for "automatically implemented properties"; I've usually heard developers use the abbreviated form "automatic properties" but "implicit" is new to me. Likewise the book talks about "overriding ==" instead of "overloading ==" reasonably frequently. It's a shame I was too busy with my own book to participate in the technical review for Effective C#, as I suspect that on at least some of these points, Bill would have been happy to amend the text accordingly. I shall, of course, transcribe my comments and send them to him.

Comment from Bill: I'll make those corrections for the subsequent printings.

What's missing?

There are some areas which I wish Bill had touched on or emphasized more. Topics such as numbers, text and chronological values could have been given some space as they frequently confuse folks (and are full of pitfalls; see Humanity: Epic Fail for more of my thoughts on this). I would personally have placed more importance on the mantra of "value types should be immutable" - it's certainly talked about, but in the context of "preferring" atomic, immutable value types - and preferring value types over reference types in rather more situations than I'd personally use. In terms of importance in avoiding shooting yourself in the foot, making sure all structs are immutable comes near the top of the list in my view.

"More Effective C#" doesn't cover those areas as far as I can tell from the table of contents, but it does go into details about generics and various aspects of C# 3 and LINQ, which are clearly part of any modern C# developer's toolkit. I certainly intend to get hold of the book to see what else I have to learn from Bill.

I think it might have been nice to have a few sections at an even higher level than the specific items in Effective C#. Topics such as:

Don't trust me: I don't know your context. Even the smartest folks can only give advice in fairly general terms in books. Don't apply this advice blindly; weigh up the arguments presented and work out how they apply to your actual code.
The importance of testing. It's possible that this was mentioned, but I don't recall it. Perhaps it's a little on the opinionated side (see previous point...) but for significant code bases, testing should be deeply ingrained in whatever process you're using. Note that although it's worth trying to keep high standards in test code, it often has a very different look and feel to production code, and different "best practices" may apply.
Encouraging "working with the language" - if you find yourself fighting the language, you may discover you can keep winning battles but losing the war. Typically changing your design to represent more idiomatic C# will make life more pleasant for everyone.
Performance: how you might decide when and how much to care.

Very few of these would be C#-specific, of course - which may be why Bill left them out. You could easily fill a whole book like that, and it would probably be horrible to read - full of platitudes rather than concrete advice. I personally think there's room for some discussion of this kind though.

Comment from Bill: The ultimate goal was to have the book be that 'nice size' you mention above. I agree that all of those concepts are important. I felt that many of these features were not C# specific (or even .NET specific) that I felt better covered elsewhere. However, that 'working with the language' was one area where I feel that I do cover. There are only a small number of negative titles (e.g "avoid" something or "do not" do something). In those cases, I tried to recommend alternatives where you would find yourself "working with the language".

Conclusion

I like Effective C# a lot. I like the fact that I've disagreed with a number of the points raised, and in disagreeing I've found myself thinking about why I disagree and in what situations each point of view may be appropriate. I worry a little about inexperienced readers who may be tempted to treat this (or any other book) as an ultimate truth to be quoted out of context and used to beat other developers into inappropriate solutions... but hopefully most readers won't be like that.

Comment from Bill: I also hope that most readers avoid that. Thank you for pointing out that I've tried very hard to explain when my advice applies, and when it doesn't. That is critical.

It's definitely encouraged me to try to write a somewhat similar book at some point... possibly not with the same organization, and probably dealing with some very different topics - but it's good to see that it can work. Whether I can pull it off as well as Bill remains to be seen, of course.

I'll look forward to reading More Effective C# - although my pile of books to review is groaning somewhat, and I should probably go through another of those first :)

Book Review: Programming C# 3.0 by Jesse Liberty and Donald Xie

skeet — Sun, 28 Sep 2008 00:59:00 GMT

Resources

The O'Reilly page (errata etc)
Jesse Liberty's page for his various books
Buy it from Amazon or Barnes and Noble

Disclaimer

One reader commented that a previous book review was too full of "this is only my personal opinion" and other such disclaimers. I think it's still important to declare the situation, but I can see how it can get annoying if done throughout the review. So instead, I've lumped everything together here. Please bear these points in mind while reading the whole review:

Obviously this book competes with C# in Depth, although probably not very much.
I was somewhat prejudiced against the book by seeing that the sole 5-star review for it on Amazon was by Jesse Liberty himself. Yes, he wanted to explain why he wrote the book and why he's proud of it, but giving yourself a review isn't the right way to go about it.
I've seen a previous edition of the book (for C# 2.0) and been unimpressed at the coverage of some of the new features.
I'm a nut for technical accuracy, particularly when it comes to terminology. More on this later, but if you don't mind reading (and then presumably using) incorrect terminology, you're likely to have a lot better time with this book than I did.
I suspect I have higher expectations for established, prolific authors such as Jesse Liberty than for newcomers to the world of writing.
I'm really not the target market for this book.

Okay, with all that out of the way, let's get cracking.

Contents and target audience

According to the preface, Programming C# 3.0 (PC# from now on) is for people learning C# for the first time, or brushing up on it. There's an expectation that you probably already know another language - it wouldn't be impossible to learn C# from the book without any prior development experience, but the preface explicitly acknowledges that it would be reasonably tough. That's a fair comment - probably fair for any book, in fact. I have yet to read anything which made me think it would be a wonderful way to teach someone to program from absolute scratch. Likewise the preface recommends C# 3.0 in a Nutshell for a more detailed look at the language, for more expert readers. Again, that's reasonable - it's clearly not aiming to go into the same level of depth as Accelerated C# 2008 or C# in Depth.

The book is split into 4 parts:

The C# language: pretty much what you'd expect, except that not all of the language coverage is in this part (most of the new features of C# 3.0 are in the second part) and some non-language coverage is included (regular expressions and collections) - about 270 pages
C# and Data: LINQ, XML (the DOM API and a bit of LINQ to XML), database access (ADO.NET and LINQ to SQL) - about 100 pages
Programming with C#: introductions to ASP.NET, WPF and Windows Forms - about 85 pages
The CLR and the .NET Framework: attributes, reflection, threading, I/O and interop - about 110 pages

As you can tell, the bulk of it is in the language part, which is fine by me and reflects the title accurately. I'll focus on that part of the book in this review, and the first chapter of part 2, which deals with the LINQ parts of C# 3.0. To be honest, I don't think the rest of the book actually adds much value, simply because they skim over the surface of their topics so lightly. Part 3 would make a reasonable series of videos - and indeed that's how it's written, basically in the style of "Open Visual Studio, start a new WinForms project, now drag a control over here" etc. I've never been fond of that style for a book, although it works well in screencasts.

The non-LINQ database and XML chapters in part 2 seemed relatively pointless too - I got the feeling that they'd been present in older editions and so had just stayed in by default. With the extra space available from cutting these, a much better job could have been done on LINQ to SQL and LINQ to XML. The latter gets particularly short-changed in PC#, with a mere 4 pages devoted to it! (C# in Depth is much less of a "libraries" book but I still found over 6 pages to devote to it. Not a lot, I'll grant you.)

Part 4 has potential, and is more useful than the previous parts - reflection, threading, IO and interop are all important topics (although I'd probably drop interop in favour of internationalization or something similar) - but they're just not handled terribly well. The threading chapter talks about using lock or Monitor, but never states that lock is just shorthand for try/finally blocks which use Monitor; no mention is made of the memory model or volatility; aborting threads is demonstrated but not warned about; the examples always lock on this without explaining that it's generally thought to be a bad idea. The IO chapter uses TextReader (usually via StreamReader) but never mentions the crucial topic of character encodings (it uses Encoding.ASCII but without really explaining it) - and most damning of all, as far as I can tell there's not a single using statement in the entire chapter. There are calls to Close() at the end of each example, and there's a very brief mention saying that you should always explicitly close streams - but without saying that you should use a using statement or try/finally for this purpose.

Okay, enough on those non-language topics - let's look at the bulk of the book, which is about the language.

Language coverage

PC# starts from scratch, so it's got the whole language to cover in about 300 pages. It would be unreasonable to expect it to provide as much attention to detail as C# in Depth, which (for the most part) only looks at the new features of C# 2.0 and 3.0. (On the other hand, if the remaining 260 pages had been given to the language as well, a lot more ground could have been covered.) It's also worth bearing in mind that the book is not aimed at confident/competent C# developers - it's written for newcomers, and delving into tricky issues like generic variance would be plain mean. However, I'm still not impressed with what's been left out:

There's no mention of nullable types as far as I can tell - indeed, the list of operators omit the null-coalescing operator (??).
Generics are really only talked about in the context of collections - despite the fact that to understand any LINQ documentation, you really will need to understand generic delegates. Generic constraints are only likewise only mentioned in the context of collections, and only what I call a "derivation type constraint" (e.g. T : IComparable<T>) (as far as I can tell the spec doesn't give this a name). There's no coverage of default(T) - although the "default value of a type" is mentioned elsewhere, with an incorrect explanation.
Collection initializers aren't explained as far as I can tell, although I seem to recall seeing one in an example. They're not mentioned in the index.
Iterator blocks (and the yield contextual keyword) are likewise absent from the index, although there's definitely one example of yield return when IEnumerable<T> is covered. The coverage given is minimal, with no mention of the completely different way that this executes compared with normal methods.
Query expression coverage is limited: although from, where, select, orderby, join and group are covered, there's no mention of let, the difference between join and join ... into, explicitly typed range variables, or query continuations. The translation process isn't really explained clearly, and the text pretty much states that it will always use extension methods.
Expression trees aren't referenced to my knowledge; there's one piece of text which attempts to mention them but just calls them "expressions" - which are of course entirely different. We'll come onto terminology in a minute.
Only the simplest (and admittedly most common by a huge margin) form of using directives is shown - no extern aliases, no namespace aliases, not even using Foo = System.Console;
Partial methods aren't mentioned.
Implicitly typed arrays aren't covered.
Static classes may be mentioned in passing (not sure) but not really explained.
Object initializers are shown in one form only, ditto anonymous object initializer expressions
Only field-like events are shown. The authors spend several pages on an example of bad code which just has a public delegate variable, and then try to blame delegates for the problem (which is really having a public variable). The solution is (of course) to use an event, but there's little to no explanation of the nature of events as pairs of methods, a bit like properties but with subscribe/unsubscribe behaviour instead of data fetch/mutate.
Anonymous methods and lambda expressions are covered, but with very little text about the closure aspect of them. This is about it: "[...] and the anonymous method has access to the variables in the scope in which they are defined:" (followed by an example which doesn't demonstrate the use of such variables at all).

I suspect there's more, but you get the general gist. I'm not saying that all of these should have been covered and in great detail, but really - no mention of nullable types at all? Is it really more appropriate in a supposed language book to spend several pages building an asynchronous file server than to actually list all the operators accurately?

Okay, I'm clearly beginning to rant by now. The limited coverage is annoying, but it's not that bad. Yes, I think the poor/missing coverage of generics and nullable types is a real problem, but it's not enough to get me really cross. It's the massive abuse of terminology which winds me up.

Accuracy

I'll say this for PC# - if you ignore the terminology abuse, it's mostly accurate. There are definitely "saying something incorrect" issues (e.g. an implication that ref/out can only be used with value type parameters; the statement that reference types in an array aren't initialized to their default value (they are - the default value is null); the claim that extension methods can only access public members of target types (they have the same access as normal - so if the extension method is in the same assembly as the target type, for instance, it could access internal members)) but the biggest problem is that of terminology - along with sloppy code, including its formatting.

The authors confuse objects, values, variables, expressions, parameters, arguments and all kinds of other things. These have well-defined meanings, and they're there for a reason. They do have footnotes explaining that they're deliberately using the wrong terminology - but that doesn't make it any better. Here are the three footnotes, and my responses to them:

The terms argument and parameter are often used interchangably, though some programmers insist on differentiating between the parameter declaration and the arguments passed in when the method is invoked.

Just because others abuse terms doesn't mean it's right for a book to do so. It's not that programmers insist on differentiating between the two - the specification does. Now, to lighten things up a bit I'll acknowledge that this one isn't always easy to deal with. There are plenty of times where I've tried really hard to use the right term and just not ended up with a satisfactory bit of wording. However, at least I've tried - and where it's easy, I've done the right thing. I wish the authors had the same attitude. (They do the same with the conditional operator, calling it "the ternary operator". It's a ternary operator. Having three operands is part of its nature - it's not a description of its behaviour. Again, lots of other people get this wrong. Perhaps if all books got it right, more developers would too.) Next up:

Throughout this book, I use the term object to refer to reference and value types. There is some debate in the fact that Microsoft has implemented the value types as though they inherited from the root class Object (and thus, you may call all of Object's methods on any value type, including the built-in types such as int.)

To me, this pretty much reads as "I'm being sloppy, but I've got half an excuse." It's true that the C# specification isn't clear on this point - although the CLI spec is crystal clear. Personally, it just feels wrong to talk about the value 5 as an object. It's an object when it's boxed, of course (and if you call any Object methods on a value type which haven't been overridden by that type, it gets boxed at that point) but otherwise I really don't think of it as an object. An instance of the type, yes - but not an object. So yes, I'll acknowledge that there's a little wiggle room here - but I believe it's going to confuse readers more than it helps them.

It's the "confusing readers more than it helps them" part which is important. I'm not above a little bit of shortcutting myself - in C# in Depth, I refer to automatically implemented properties as "automatic properties" (after explicitly saying what I'm doing) and I refer to the versions of C# as 1, 2 and 3 instead of 1.0, 1.2, 2.0 and 3.0. In both these cases, I believe it adds to the readability of the book without giving any room for confusion. That's very different from what's going on in PC#, in my view. I've saved the most galling example of this for last:

As noted earlier, btnUpdate and btnDelete are actually variables that refer to the unnamed instances on the heap. For simplicity, we'll refer to these as the names of the objects, keeping in mind that this is just short-hand for "the name of the variables that refer to the unnamed instances on the heap."

This one's the killer. It sounds relatively innocuous until you see the results. Things like this (from P63):

ListBox myListBox; // instantiate a ListBox object

No, that code doesn't instantiate anything. It declares a variable - and that's all. The comment isn't non-sensical - the idea of some code which does instantiate a ListBox object clearly makes sense - but it's not what's happening in this code (in C# - it would in C++, which makes it even more confusing). That's just one example - the same awful sloppiness (which implies something completely incorrect) permeates the whole book. Time and time again we're told about instances being created when they're not. From P261:

The Clock class must then create an instance of this delegate, which it does on the following line:

public SecondChangeHandler SecondChanged;

Why do I care about this so much? Because I see the results of it on the newsgroups, constantly. How can I blame developers for failing to communicate properly about the problems they're having if their source of learning is so sloppy and inaccurate? How can they get an accurate mental model of the language if they're being told that objects are being instantiated when they're not? Communication and a clear mental model are very important to me. They're why I get riled up when people perpetuate myths about where structs "live" or how parameters are passed. PC# had me clenching my fists on a regular basis.

These are examples where the authors apparently knew they were abusing the terminology. There are other examples where I believe it's a genuine mistake - calling anonymous methods "anonymous delegates" or "statements that evaluate to a value are called expressions" (statements are made up of expressions, and expressions don't have to return a value). I can certainly sympathise with this. Quite where they got the idea that HTML was derived from "Structured Query Markup Language" I don't know - the word "Query"should have been a red flag - but these things happen.

In other places the authors are just being sloppy without either declaring that they're going to be, or just appearing to make typos. In particular, they're bad at distinguishing between language, framework and runtime. For instance:

"C# combines the power and complexity of regular expression syntax [...]" - no, C# itself neither knows nor cares about regular expressions. They're in the framework.
(When talking about iterator blocks) "All the bookkeeping for keeping track of which element is next, resetting the iterator, and so forth is provided for you by the Framework." - No, this time it is the C# compiler which is doing all the work. (It doesn't support reset though.)
"Strings can also be created using verbatim string literals, which start the at (@) symbol. This tells the String constructor that the string should be used verbatim [...]" - No, the String constructor doesn't know about verbatim string literals. They're handled by the C# compiler.
"The .NET CLR provides isolated storage to allow the application developer to store data on a per-user basis." I very much doubt that the CLR code has any idea about this. I expect it to be in the framework libraries.

Again, if books don't get this right, how do we expect developers to distinguish between the three? Admittedly sometimes it can be tricky to decide where responsibility lies - but there are plenty of clearcut cases where PC# is just wrong. I doubt that the authors really don't know the difference - they just don't seem to think it's important to get it right.

Code

I'm mostly going to point out the shortcomings of the code, but on the plus side I believe almost all of it will basically work. There's one point at which the authors have both a method and a variable with the same name (which is already in the unconfirmed errata) and a few other niggles, but they're relatively rare. However:

The code frequently ignores naming conventions. Method and class names sometimes start with lower case, and there's frequent use of horrible names beginning with "my" or "the".
The authors often present several pages of code together, and then take them apart section by section. This isn't the only book to do this by a long chalk, but I wonder - does anyone really benefit from having the whole thing in a big chunk? Isn't it better to present small, self-contained examples?
As mentioned before, the uses of using statements are few and far between.
The whitespace is all over the place. The indentation level changes all the time, and sometimes there are outdents in the middle of blocks. Occasionally newlines have actually been missed out, and in other cases (particularly at the start of class bodies) there are two blank lines for no reason at all. (The latter is very odd in a book, where vertical whitespace is seen as extremely valuable.) Sometimes there's excessive (to my mind) spacing Just as an example (which is explicitly labelled as non-compiling code, so I'm not faulting it at all for that):
using System.Console;
class Hello
{
    static void Main()
    {
    WriteLine("Hello World");
   }
}
I promise you that's exactly how it appears in the book. Now this may have started out as a fault of the type-setter, but the authors should have picked it up before publication, IMO. I could understand there being a few issues like this (proof-reading code really is hard) but not nearly as many as there are.
There are examples of mutable structs (or rather, there's at least one example), and no warning at all that mutable value types are a really, really bad idea.

Again, I don't want to give the impression I'm an absolute perfectionist when it comes to code in book. For the sake of keeping things simple, sometimes authors don't seal types where they should, or make them immutable etc. I'm not really looking for production-ready code, and indeed I made this very point in one of the notes for C# in Depth. However, I draw the line at using statements, which are important and easy to get right without distracting the reader. Likewise giving variables good names - counter rather than ctr, and avoiding those the and my prefixes - makes a competent reader more comfortable and can transfer good habits to the novice via osmosis.

Writing style and content ordering

Time for some good news - when you look beyond the terminology, this is a really easy book to read. I don't mean that everything in it is simplistic, but the style rarely gets in the way. It's not dry, and some of the real-world analogies are very good. This may well be Jesse Liberty's experience as a long-standing author making itself apparent.

In common with many O'Reilly books, there are two icons which usually signify something worth paying special attention to: a set of paw prints indicating a hint or tip, and a mantrap indicating a commonly encountered issue to be aware of. Given the rest of the review, I suspect you'd be surprised if I agreed with all of the points made in these extra notes - and indeed there are some issues - but most of them are good.

Likewise there are also notes for the sake of existing Java and C++ developers, which make sense and are useful.

I don't agree with some of the choices made in terms of how and when to present some concepts. I found the way of explaining query expressions confusing, as it interleaved "here's a new part of query expressions" with "here's a new feature (e.g. anonymous types, extension methods)." It will come as no surprise to anyone who's read C# in Depth that I prefer the approach of presenting all the building blocks first, and then showing how query expressions use all those features. There's a note explaining why the authors have done what they've done, but I don't buy it. One important thing with the "building blocks first" approach is to present a preliminary example or two, to give an idea of where we're headed. I've forgotten to do that in the past (in a talk) and regretted it - but I don't regret the overall way of tackling the topic.

On a slightly different note, I would have presented some of the earlier topics in a different order too. For instance, I regard structs and interfaces as more commonly used and fundamental topics than operator overloading. (While C# developers tend not to create their own structs often, they use them all the time. When was the last time you wrote a program without an int in it?) This is a minor nit - and one which readers may remember I also mentioned for Accelerated C# 2008.

There's one final point I'd like to make, but which doesn't really fit anywhere else - it's about Jesse Liberty's dedication. Most people dedicate books to friends, colleages etc. Here's Jesse's:

This book is dedicated to those who come out, loud, and in your face and in the most inappropriate places. We will look back at this time and shake our heads in wonder. In 49 states, same-sex couples are denied the right to marry, though incarcerated felons are not. In 36 states, you can legally be denied housing just for being q-u-e-e-r. In more than half the states, there is no law protecting LGBT children from harassment in school, and the suicide rate among q-u-e-e-r teens is 400 percent higher than among straight kids. And, we are still kicking gay heroes out of the military despite the fact that the Israelis and our own NSA, CIA, and FBI are all successfully integrated. So yes, this dedication is to those of us who are out, full-time.

(I've had to spell out q-u-e-e-r as otherwise the blog software replaces it with asterisks. Grr.) I'm straight, but I support Jesse's sentiment 100%. I can't remember when I first started taking proper notice of the homophobia in the world, but it was probably at university. This dedication does nothing to help or hinder the reader with C#, but to my mind it still makes it a better book.

Conclusion

In short, I'm afraid I wouldn't recommend Programming C# 3.0 to potential readers. There are much better books out there: ones which won't make it harder for the reader to talk about their code with others, in particular. It's not all bad by any means, but the mixture of sloppy use of terminology and poor printed code is enough of a problem to make me give a general thumbs down.

Next up will be CLR via C#, by Jeffrey Richter.

Response from Jesse Liberty

As normal, I mailed the author (in this case just Jesse Liberty - I confess I didn't look for Donald Xie's email address) and very promptly received a nice response. He asked me to add the following as his reaction:

I believe the book is very good for most real-world programmers and the publisher and I are dedicated to making the next revision a far better book, by correcting some of the problems you point out, and by beefing up the coverage of the newer features of the language.

Also as normal, I'll be emailing Jesse with a list of the errors I found, so hopefully they can be corrected for the next edition.

Book review: Accelerated C# 2008 by Trey Nash

skeet — Fri, 01 Aug 2008 22:05:41 GMT

Time for another book review, and this time it's a due to a recommendation from a reader who has this one, C# in Depth and Head First C#.

Resources

Introduction and disclaimer

My normal book review disclaimer applies, but probably more so than ever before. Yes, Accelerated C# 2008 is a competitor to C# in Depth. They're different in many ways, but many people would no doubt be in the target audience for both books. If you meet that criterion, please be aware that as the author of C# in Depth I can't possibly be 100% objective when reviewing another C# book. That said, I'll try to justify my opinions everywhere I can.

Target audience and content overview

Accelerated C# 2008 is designed to appeal to existing developers with experience in an OO language. As one of the Amazon reviews notes, you may struggle somewhat if you don't have any .NET experience beforehand - while it should be possible to read it knowing only Java or C++, there are various times where a certain base level of knowledge is assumed and you'll want to refer to MSDN for some background material. If you come at the book with no OO experience at all, I expect you'll have a hard time. Chapter 4 does cover the basics of OO in .NET (classes, structs, methods, properties etc) this isn't really a beginner's book.

In terms of actual content covered, Accelerated C# 2008 falls somewhere between C# in Depth (almost purely language) and C# 3.0 in a Nutshell (language and then core libraries). It doesn't attempt to cover all the core technologies (IO, reflection, security, interop etc are absent) but it goes into detail beyond the C# language when it comes to strings, exceptions, collections, threading and more. As well as purely factual information, there's a lot of guidance as well, including a whole chapter entitled "In Search of C# Canonical Forms."

General impressions

I'd like to make it clear to start with that I like the book. I have a number of criticisms, none of which I'm making up for the sake of being critical - but that in no way means it's a bad book at all. It's very unlikely that you know everything in here (I certainly didn't) and the majority of the guidance is sound. The code examples are almost always self-contained (a big plus in my view) and Trey's style is very readable. Where there are inaccuracies, they're usually pretty harmless, and the large amount of accurate and insightful material makes up for them.

Just as I often compare Java to C# in my book, so Trey often compares C++ to C# in his. While my balance of C# to C++ knowledge is such that these comments aren't particularly useful to me, I can see them being good for a newcomer to C# from a C++ background. I thought there might have been a few too many comparisons (I understood the point about STL and lambdas/LINQ the first time round...) but that's just a minor niggle.

Where C# in Depth is primarily a "read from start to finish" book and C# 3.0 in a Nutshell is primarily a reference book (both can be used the other way, of course) Accelerated C# 2008 falls between the two. It actually achieves the best of both worlds to a large extent, which is an impressive feat. The ordering could be improved (more on this later on) but the general feeling is very good.

One quick word about the size of the book in terms of content: if you're one of those people who judges the amount of useful content in a book on its page count, it's worth noting that the font in this book is pretty small. I would guess that it packs about 25% more text per page than C# in Depth does, taking its "effective" page count from around 500 to 625. Also, the content is certainly meaty - you're unlikely to find yourself skimming over loads of simple stuff trying to get to the good bits. Speaking of "getting to the good bits" let's tackle my first significant gripe.

Material organisation

If you look at the tables of contents for Accelerated C# 2008 and Accelerated C# 2005, you'll notice that the exact same chapter titles in the 2005 edition carry over in the same order in the 2008 edition. There are three extra chapters in the new edition, covering extension methods, lambda expressions and LINQ. That's not to say that the content of the "duplicate" chapters is the same as before - C# 3.0 features are introduced in the appropriate place within existing chapters. In terms of ordering the chapters, I think it would be have been much more appropriate to keep the last chapter of the old edition - "In Search of C# Canonical Forms" - as the last chapter of the new edition. Apart from anything else, that would allow it to include hints and tips involving the new C# 3 features which are currently covered later. It really feels like a "wrapping up" chapter, and deserves to be last.

That's not the only time that the ordering felt strange, however. Advanced topics (at least ones which feel advanced to me) are mixed in with fairly basic ones. For instance, in the chapter on exceptions, there's a section about "exception neutrality" which includes details about constrained execution regions and critical finalizers. All interesting stuff - even though I wish there were more of a prominent warning saying, "This is costly to both performance and readability: only go to these lengths when you really, really need to." However, this comes before a section about using try/finally blocks and the using statement to make sure that resources are cleaned up however a block is exited. I can't imagine anyone who knows enough C# to take in the exception neutrality material also not knowing about try/finally or the using statement (or how to create your own custom exception class, which comes between these two topics).

Likewise the chapter which deals with collections, including generic ones, comes before the chapter on generics. If I were a reader who didn't know generics already, I think I'd get very confused reading about ICollection<T> without knowing what the T meant. Now don't get me wrong: ordering material so that you don't get "circular references" is often hard if not impossible. I just think it could have been done better here.

Aiming too deep?

It's not like me to criticise a book for being too deep, but I'm going to make an exception here. Every so often, I came away from a topic thinking that it would have been better covered a little bit more lightly. Sometimes this was because a running example became laborious and moved a long way from anything you were actually likely to want to do in real life. The sections on "borrowing from functional programming" and memoization/currying/anonymous recursion felt guilty of this. It's not that they're not interesting topics, but the examples picked didn't quite work for me.

The other problem with going deep is that you really, really need to get things right - because your readers are less likely to spot the mistakes. I'll give three examples here:

Trey works hard on a number of occasions to avoid boxing, and points it out each time. Without any experience in performance tuning, you'd be forgiven for thinking that boxing is the primary cause of poor performance in .NET applications based on this book. While I agree that it's something to be avoided where it's possible to do so without bending the design out of shape, it doesn't deserve to be laboured as much as it is here. In particular, Trey gives an example of a complex number struct and how he's written appropriate overloads etc to avoid boxing. Unfortunately, to calculate the magnitude of the complex number (used to implement IComparable in a manner which violates the contract, but that's another matter) he uses Math.Pow(real, 2) + Math.Pow(img, 2). Using a quick and dirty benchmark, I found that using real * real + img * img instead of Math.Pow made far, far more difference than whether or not the struct was boxed. (I happen to think it's more readable code too, but never mind.) There was nothing wrong with avoiding the boxing, but in chasing the small performance gains, the big ones were missed.
In the chapter on threading, there are some demonstrations of lock-free programming (before describing locking, somewhat oddly - and without describing the volatile modifier). Now, personally I'd want to discourage people from attempting lock-free programming at all unless they've got a really good reason (with evidence!) to support that decision - but if you're going to do it at all, you need to be hugely careful. One of the examples basically has a load of threads starting and stopping, updating a counter (correctly) using Interlocked.Increment/Decrement. Another thread monitors the count and periodically reports it - but unfortunately it uses this statement to do it:

threadCount = Interlocked.Exchange(ref numberThreads, numberThreads);

The explanation states: "Since the Interlocked class doesn't provide a method to simply read an Int32 value in an atomic operation, all I'm doing is swapping the numberThreads variable's value with its own value, and, as a side effect, the Interlocked.Exchange method returns to me the value that was in the slot." Well, not quite. It's actually swapping the numberThreads variable's value with a value evaluated at some point before the method call. If you rewrite the code like this, it becomes more obviously wrong:

int tmp = numberThreads;
Thread.Sleep(1000); // What could possibly happen during this time, I wonder?
threadCount = Interlocked.Exchange(ref numberThreads, tmp);

The call to Thread.Sleep is there to make it clear that numberThreads can very easily change between the initial read and the call to Interlocked.Exchange. The correct fix to the code is to use something like this:

threadCount = Interlocked.CompareExchange(ref numberThreads, 0, 0);

That sets numberThreads atomically to the value 0 if (and only if) its value is already 0 - in other words, it will never actually change the value, just report it. Now, I've laboured the explanation of why the code is wrong because it's fairly subtle. Obvious errors in books are relatively harmless - subtle ones are much more worrying.
As a final example for this section, let's look at iterator blocks. Did you know that any parameters passed to methods implemented using iterator blocks become public fields in the generated class? I certainly didn't. Trey pointed out that this meant they could easily be changed with reflection, and that could be dangerous. (After looking with reflector, it appears that local variables within the iterator block are also turned into public fields.) Now, leaving aside the fact that this is hugely unlikely to actually bite anyone (I'd be frankly amazed to see it as a problem in the wild) the suggested fix is very odd.

The example Trey gives is where originally a Boolean parameter is passed into the method, and used in two places. Oh no! The value of the field can be changed between those two uses, which could lead to problems! True. The supposed fix is to wrap the Boolean value in an immutable struct ImmutableBool, and pass that in instead. Now, why would that be any better? Certainly you can't change the value within the struct - but you can easily change the field's value to be a completely different instance of ImmutableBool. Indeed, the breakage would involve exactly the same code, just changing the type of the value. The other train of thought which suggests that this approach would fail is that bool is already immutable, so it can't be the mutability of the type of the field that causes problems. I'm sure there are much more useful things that Trey could have said in the two and a half pages he spent describing a broken fix to an unimportant problem.

Sorry, that was getting ranty for a bit... but I hope you understand why. Before concluding this review, let's look at one chapter which is somewhat different to the rest, and which I've mentioned before:

In Search of C# Canonical Forms (aka "Design and Implementation Guidelines" :)

I'd been looking forward to this part of the book. I'm always interested in seeing what other people think the most important aspects of class design are. The book doesn't go into much detail about abstract orientation (in this chapter, anyway - there's plenty scattered through the book) but concentrates on core interfaces you might implement, etc. That's fine. I'm still waiting for a C# book to be written to truly be on a par with Effective Java (I have the second edition waiting to be read at work...) but I wasn't expecting it all to be here. So, was this chapter worth the wait?

Somewhat. I was very glad to see that the first point around reference types was "Default to sealed classes" - I couldn't agree more, and the arguments were well articulated. Many other guidelines were either entirely reasonable or at least I could go either way on. There were a few where I either disagreed or at least would have put things differently:

Implementing cloning with copy constructors: one point about cloning which wasn't mentioned is that (to quote MSDN) "The resulting clone must be of the same type as or a compatible type to the original instance." The suggested implementation of Clone in the book is to use copy constructors. This means that every subclass must override Clone to call its own copy constructor, otherwise the instance returned will be of the wrong type. MemberwiseClone always creates an instance of the same type. Yes, it means the constructor isn't called - but frankly the example given (performing a database lookup in the constructor) is a pretty dodgy cloning scenario in the first place, in my view. If I create a clone and it doesn't contain the same data as the original, there's something wrong. Having said that, the caveats Trey gives around MemberwiseClone are all valid in and of themselves - we just disagree about their importance. The advice to not actually implement ICloneable in the first place is also present (and well explained).
Implementing IDisposable: Okay, so this is a tough topic, but I was slightly disappointed to see the recommendation that "it's wise for any objects that implement the IDisposable interface to also implement a finalizer [...]" Now admittedly on the same page there's the statement that "In reality, it's rare that you'll ever need to write a finalizer" but the contradiction isn't adequately resolved. A lot of people have trouble understanding this topic, so it would have been nice to see really crisp advice here. My 20 second version of it is: "Only implement a finalizer if you're holding on to resources which won't be cleaned up by their own finalizers." That actually cuts out almost everything, unless you've got an IntPtr to a native handle (in which case, use SafeHandle instead).
- As a side note, Trey repeatedly claims that "finalizers aren't destructors" which irks me somewhat as the C# spec (the MS version, anyway) uses the word "destructor" exclusively - a destructor is the way you implement a .NET finalizer in C#. It would be fine to say "destructors in C# aren't deterministic, unlike destructors in C++" but I think it's worth acknowledging that the word has a valid meaning in the context of C#. Anyway...
Implementing equality comparisons: while this was largely okay, I was disappointed to see that there wasn't much discussion of inheritance and how it breaks equality comparisons in a hard-to-fix way. There's some mention of inheritance, but it doesn't tackle the issue I think is thorniest: If I'm asking one square whether it's equal to another square, is it enough to just check for everything I know about squares (e.g. size and position)? What about if one of the squares is actually a coloured square - it has more information than a "basic" square. It's very easy to end up with implementations which break reflexivity, simply because the question isn't well-defined. You effectively need to be asking "are these two objects equal in <this> particular aspect" - but you don't get to specify the aspect. This is an example where I remember Effective Java (first edition) giving a really thorough explanation of the pitfalls and potential implementations. The coverage in Accelerated C# 2008 is far from bad - it just doesn't meet the gold standard. Arguably it's unfair to ask another book to compete at that level, when it's trying to do so much else as well.
Ordering: I mentioned earlier on that the complex number class used for a boxing example failed to implement comparisons appropriately. Unfortunately it's used as the example specifically for "how to implement IComparable and IComparable<T>" as well. To avoid going into too much detail, if you have two instances x and y such that x != y but x.Magnitude == y.Magnitude, you'll find x.CompareTo(y) == y.CompareTo(x) (but with a non-zero result in both cases). What's needed here is a completely different example - one with a more obvious ordering.
Value types and immutability: Okay, so the last bullet on the value types checklist is "Should this struct be immutable? [...] Values are excellent candidates to be immutable types" but this comes after "Need to boxed instances of value? Implement an interface to do so [...]" No! Just say no to mutable value types to start with! Mutable value types are bad, bad, bad, and should be avoided like the plague. There are a very few situations where it may be appropriate, but to my mind any advice checklist for implementing structs should make two basic points:
- Are you sure you really wanted a struct in the first place? (They're rarely the right choice.)
- Please make it immutable! Pretty please with a cherry on top? Every time a struct is mutated, a cute kitten dies. Do you really want to be responsible for that?

Conclusion

At the risk - nay, certainty - of repeating myself, I'm going to say that I like the book despite the (sometimes subjective) flaws pointed out above. As Shakespeare wrote in Julius Caesar, "The evil men do lives after them. The good is oft interred with their bones." So it is with book reviews - it's a lot easier to give specific examples of problems than it is to report successes - but the book does succeed, for the most part. Perhaps the root of almost all my reservations is that it tries to do too much - I'm not sure whether it's possible to go into that much detail and cater for those with little or no previous C# experience (even with Java/C++) and keep to a relatively slim volume. It was a very lofty goal, and Trey has done very well to accomplish what he has. I would be interested to read a book by him (and hey, potentially even collaborate on it) which is solely on well-designed classes and libraries.

In short, I recommend Accelerated C# 2008, with a few reservations. Hopefully you can judge for yourself whether my reservations would bother you or not. I think overall I slightly prefer C# 3.0 in a Nutshell, but the two books are fairly different.

Reaction

I sent this to Trey before publishing it, as is my custom. He responded to all my points extremely graciously. I'm not sure yet whether I can post the responses themselves - stay tuned for the possibility, at least. My one problem with reviewing books is that I end up in contact with so many other authors who I'd like to work with some day, and that number has just increased again...

Judging a book by its cover (or title)

skeet — Fri, 18 Jul 2008 19:50:24 GMT

I've ranted about versioning before (and indeed in C# in Depth). I still believe that Microsoft didn't do the world any favours when they introduced a relatively minor set of changes (just libraries, albeit important ones) with .NET 3.0 and a more major set of changes (languages, LINQ, core library improvements) with .NET 3.5. Using 2.5 and 3.0 would have made more sense, IMO. But never mind.

The fact is, people are confused about what version number applies to what. A number of people claim to be using C# 3.5 when they mean either C# 3.0 or .NET 3.5. (For a quick reference of what's actually what, see my article on the issue.)

Okay, so far it's the fault of Microsoft for being confusing and the fault of developers for not keeping up. Both of these are far more forgiveable in my view than being flat out wrong as many books are at the moment. I don't believe this is any indication on the quality of the book itself (Accelerated C# 2008 is pretty good so far, for example) but I still think it's pretty awful to make a title so confusing. So, here are some bad titles and others which use version numbers appropriately. (I've left out titles like Head First C# and C# in Depth which don't specify version numbers.)

Bad

Professional C# 2008 (Wrox)
Pro C# 2008 and the .NET 3.5 Platform (Apress) (only partly incorrect, of course)
Murach's C# 2008 (Mike Murach and Associates)
Accelerated C# 2008 (Apress)
Illustrated C# 2008 (Apress)
Pro LINQ: Language Integrated Query in C# 2008 (APress)
Pro ASP.NET 3.5 in C# 2008 (Apress) (again, only partially incorrect)
Beginning C# 2008 (Apress)
Beginning C# 2008 Databases (Apress)

Good

C# 3.0 in a Nutshell (O'Reilly)
Programming C# 3.0 (O'Reilly)
C# 3.0 Cookbook (O'Reilly)
C# 3.0 Design Patterns (O'Reilly)
C# 3.0 Pocket Reference (O'Reilly)
Pro C# with .NET 3.0 (Apress)
Beginning C# 3.0 (Wrox)
C# 3.0 Unleashed: With the .NET Framework 3.5 (Sams)

Okay

This is the "well, just about" list - because they're referring to "Microsoft Visual C# 2008" instead of C# 2008, it's referring to the IDE instead of the language. I think it's better to name a book after the language instead of the tool you use to write in the language, personally...

Beginning Microsoft Visual C# 2008 (Wrox)
Microsoft Visual C# 2008 Step By Step (Microsoft)
Programming Microsoft Visual C# 2008 (Microsoft)
Microsoft Visual C# 2008 Express Edition: Build a Program Now! (Microsoft)

Notice a pattern? If anyone at Apress is reading this (unlikely, I know) - there's no such thing as "C# 2008".

Rant over for the moment. With any luck I might be able to finish reading Accelerated C# 2008 fairly soon, and give a proper book review.

Guest post: Joe Albahari reviews C# in Depth

skeet — Fri, 06 Jun 2008 16:22:00 GMT

Joe Albahari, co-author of the excellent C# 3.0 in a Nutshell (previously reviewed here) kindly agreed to review C# in Depth. Not only has he provided the review below, but he also supplied several pages of notes made while he was reading it. Many of those notes have been incorporated into the C# in Depth notes page - it's always good to include thoughtful feedback. (And I always welcome more, hint hint.)

Without further ado, here's Joe's review.

C# in Depth: Review

After having been invited to review this book by two people at Manning—as well as Jon himself—I figure it's about time I came forward! Bear in mind that I'm not a typical reader: I'm an author, and this makes me more critical than most. This is especially true given that I wrote C# 3.0 in a Nutshell with a coauthor (imagine two people constantly searching for ways to improve each others' work!). So I will do my best to compensate and strive to be fair. Please post a comment if you feel I've missed the mark!

Scope

While most other C# books cover the language, the CLR and at least some aspects of the Framework, C# in Depth concentrates largely on just the language. You won't find discussions on memory management, assemblies, streams and I/O, security, threading, or any of the big APIs like WPF or ASP.NET. This is good in that doesn't duplicate the books already out there, as well as giving more space for the language.

You might expect that a book focusing on the C# language itself would cover all of it. But interestingly, the book covers only about a quarter of the C# language, namely the features new to C# 2 and C# 3. This sets its target audience: programmers who already know C# 1, but have not yet switched to C# 2 and 3. This creates a tight focus, allowing it to devote serious space to topics such as generics, nullable types, iterators and lambda expressions. It's no exaggeration to say that this book covers less than one tenth of the ground of most other C# books, but gives that ground ten times as much attention.

Organization and Style

The book is divided into three parts:

Preliminaries (delegates and the type system)
Features new to C# 2.0
Features new to C# 3.0

I like this organization: it presents topics in an order roughly similar to how I teach when giving tutorials on LINQ—starting with the foundations of delegates and generics, before moving on to iterators and higher-order functions, and then finally LINQ. Sometimes the routes are a little circuitous and involve some huffing and puffing, but the journey is worthwhile and helps to solidify concepts.

C# in Depth is a tutorial that gradually builds one concept upon another and is designed primarily for sequential reading. The examples don't drag on over multiple sections, however, so you can jump in at any point (assuming you understand the preceding topics). The examples are all fairly short, too, which is very much in my taste. In fact, I would say Jon and I think very much alike: when he expresses an opinion, I nearly always agree wholeheartedly.

A big trap in writing tutorials, is assuming knowledge of topics that you teach later. This book rarely falls victim to this. The writer is also consistent in his use of terminology—and sticks with the C# Language Specification which I think sets a good example to all authors. Jon is not sloppy with concepts and is careful in his wording to avoid misinterpretation. One thing that comes through is that Jon really understands the material deeply himself.

If I were to classify this book as beginner/intermediate/advanced, I'd say intermediate-to-advanced. It's quite a bit more advanced than, say, Jesse's tutorial “Programming C#”.

The layout of the book is pleasing—I particularly like the annotations alongside the code listings.

Content

In the first section, "Preparing for the Journey," the book does cover a few C# 1 topics, namely delegates and C#'s type system. Jon's handling of these topics is excellent: his discussion of static, explicit and safe typing is clear and helpful, as is the section on value types versus reference types. I particularly liked the section "Dispelling Myths"—this is likely to be of use even to experienced developers. This chapter, in fact, leaves the reader pining for more advanced C# 1 material.

The C# 2 features are very well covered. The section on generics includes such topics as their handling by the JIT compiler, the subtleties of type inference, a thorough discussion on constraints, covariance/contravariance limitations, and comparisons with Java's generics and C++'s templates. Nullable types are covered similarly well, with suggested patterns of use, as are anonymous methods and iterators.

The C# 3 features are also handled well. I like how Jon introduces expression trees—first building them programmatically, and then showing how the compiler provides a shortcut via lambda expressions. The book covers query expressions and the basics of LINQ, and includes a brief explanation of each of the standard query operators in an appendix. There's also a chapter called “LINQ Beyond Collections” which briefly introduces the LINQ to SQL, LINQ to DataSet and LINQ to XML APIs.

Throughout the book, Jon goes to some lengths to explain not just “what”, but “why”. This book isn't for people who want to get in and out quick so they can get their job done and out of the way—it's for people who enjoy working elegantly with their tools, through a rich understanding of the language's background, subtleties and nuances.

Of course, digesting all this is a bit of work (Chapter 3's summary opens with the word "Phew!"). Despite this, I think Jon does a good job at explaining difficult things well. I don't think I've seen any IL listings in the book, which is a good sign in general. I'm always wary when an author, in explaining a C# concept, says, "to understand XYZ, we must examine the IL". I take issue with this: rarely, if ever, does one need to look at IL to understand C#, and doing so creates unnecessary complication by choosing the wrong level of abstraction. That isn't to saying looking at IL isn't useful for a deeper understanding of the CLR—but only after first teaching C# concepts independently of IL.

What's Missing

It was in Jon's design critieria not build a tome—instead to write a small(ish) book that complements rather than replaces books such as C# 3.0 in a Nutshell. Most things missing from C# in Depth are consistent with its focus (such as the CLR, threading, .NET Framework, etc.) The fact that C# in Depth excludes the features of C# that were introduced prior to version 2 is a good thing if you're looking for a “delta” book, although, of course, it makes it less useful as a language reference.

The book's treatment of LINQ centres largely on LINQ to Objects. If you're planning on learning C# 3.0 so that you can query databases through LINQ, the book's focus is not ideal, if read in isolation. I personally prefer the approach of covering "remote" query architecture earlier and in more detail (in conjunction with the canonical API, LINQ to SQL) - so that when it comes time to teach query operators such as SelectMany, Group and Join, they can be demonstrated in the context of both local and database queries. I also strive, when writing on LINQ, to cover enough querying ground that readers can "reproduce" their SQL queries in LINQ—even though it means having to get sidetracked with API practicalities. Of course, getting sidetracked with API practicalities is undesirable for a language-centric book such as C# in Depth, and so the LINQ to Objects focus is understandable. In any case, reading Chapters 8-10 of C# 3.0 in a Nutshell would certainly fill in the gaps. Another complementary book would be Manning's LINQ in Action (this book is well-reviewed on Amazon, though I've not yet read it).

Summary

This book is well written, accurate and insightful, and complements nearly every other book out there. I would recommend it to anyone wanting a thorough "inside" tutorial on the features new to C# 2 and 3.

Programming "in" a language vs programming "into" a language

skeet — Wed, 23 Apr 2008 18:47:15 GMT

I'm currently reading Steve McConnell's Code Complete (for the first time - yes, I know that's somewhat worrying) and there was one section was disturbed me a little. For those of you with a copy to hand, it's in section 4.3, discussing the difference between programming in a language and programming into a language:

Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer's thoughts will also be primitive.

Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.

Now don't get me wrong - I can see where he's coming from, and the example he then provides (Visual Basic - keeping the forms simple and separating them from business logic) is fine, but he only seems to give one side of the coin. Here's a different - and equally one-sided - way of expressing the same terms:

Programmers who program "in" a language understand that language's conventions and idioms. They write code which integrates well with other libraries, and which can be easily understood and maintained by other developers who are familiar with the language. They benefit from tools which have been specifically designed to aid coding in the supported idioms.

Programmers who program "into" a language will use the same ideas regardless of their target language. If their style does not mesh well with the language, they will find themselves fighting against it every step of the way. It will be harder to find libraries supporting their way of working, and tools may well prove annoying. Other developers who come onto the project later and who have experience in the language but not the codebase will find it hard to navigate and may well accidentally break the code when changing it.

There is a happy medium to be achieved, clearly. You certainly shouldn't restrict your thinking to techniques which are entirely idiomatic, but if you find yourself wanting to code in a radically different style to that encouraged by the language, consider changing language if possible!

If I were attacking the same problem in C# 1 and C# 3, I could easily end up with radically different solutions. Some data extraction using LINQ in a fairly functional way in C# 3 would probably be better solved in C# 1 by losing some of the functional goodness than by trying to back-port LINQ and then use it without the benefit of lambda expressions or even anonymous methods.

Accents and Conventions

That's just between different versions of the same language. Between different actual languages, it can get much worse. If you've ever seen Java code written in a C++ style or vice versa, you'll know what I mean. I've previously referred to this in terms of speaking a language with an accent - you can speak C# with a Java accent just as you can speak French with an English accent. Neither is pleasant.

At the lowest level, this is likely to be about conventions - and I'm pretty sure that when Steve writes "Invent your own coding conventions, standards, class libraries, and other augmentations" he doesn't actually mean us to do it in a gratuitous fashion. It can be worth deviating from the "platform favoured" conventions sometimes, particularly if those differences are invisible to clients, but it should always be done with careful consideration. In a Java project I worked on a few years ago, we took the .NET naming conventions for interfaces (an I prefix) and constants (CamelCasing instead of SHOUTY_CAPS). Both of these made the codebase feel slightly odd, particularly where Java constants were used near our constants - but I personally found the benefits to be worth the costs. Importantly, the whole team discussed it before making any decisions.

Design Patterns

At a slightly higher level, many design patterns are just supported much, much better by some languages than others. The iterator pattern is a classic example. Compare the support for it from Java 6 and C# 2. On the "client" side, both languages have specific syntax: the enhanced for loop in Java and the foreach loop in C#. However, there is one important difference: if the iterator returned by GetEnumerator implements IDisposable (which the generic form demands, in fact) C# will call Dispose at the end of the loop, no matter how that occurs (reaching the end of the sequence, breaking early, an exception being thrown, etc). Java has no equivalent of this. Imagine that you want to write a class to iterate over the lines in a file. In Java, there's just no safe way of representing it: you can make your iterator implement Closeable but then callers can't (safely) use the enhanced for loop. You can make your code close the file handle when it reaches the end, but there's no guarantee that will happen.

Then consider the "server" side of the iterator - the code actually providing the data. Java is like C# 1 - there's no specific support for implementing an iterator. In C# 2 and above, iterator blocks (i.e. methods with yield statements) make life much, much easier. Writing iterators by hand can be a real pain. Reading a file line by line isn't too bad, leaving aside the resource lifetime issue - but the complexity can balloon very quickly. Off by one errors are really easy to introduce.

So, if I were tackling a project which required reading text files line by line in various places, what would I do? In Java, I would take the reasonably small hit of a while loop in each place I needed it. In C# I'd write a LineReader class (if I didn't already have one!) and use a more readable foreach loop. The contortions involved in introducing that idea into Java just wouldn't be worth the effort.

At a much higher level, we get into whole programming styles and paradigms. If your natural inclination is to write imperative code, you're likely to create a mess (or get very frustrated) in a functional language. If the problem really does call for a functional language, find someone else to help you think in a more functional way. If the problem suits imperative programming just as well as it does functional programming, see if you can change the environment to something more familiar.

Conclusion

I'm not suggesting that Steve's point isn't valid - but he's done his readers a disservice by only presenting one side of the matter. Fortunately, the rest of the book (so far) is excellent and humbling - to such a degree that this minor quibble stuck out like a sore thumb. In a book which had more problems, I would probably barely have even noticed this one.

There's another possibility, of course - I could be competely wrong; maybe I've been approaching problems from a restrictive viewpoint all this time. How about you?

Book review: C# 3.0 in a Nutshell

skeet — Mon, 31 Mar 2008 15:16:29 GMT

Resources:

Book's web site (includes various tools such as LINQPad)
Amazon
Errata

Introduction

The original C# in a Nutshell was the book I cut my C# teeth on, so to speak. Basically I read it (well, the bits which weren't just reproductions of MSDN - gone in this edition, thankfully), played around in Visual Studio, and then started to answer questions on the C# newsgroup. (That's a great way of learning useful things, by the way - find another person's problem which sounds like it's one you might face in the future, then research the answer.)

Five and a half years later (Google groups suggests I cut my teeth in the C# newsgroup in August 2002) I've just been reading C# 3.0 in a Nutshell, by Joe and Ben Albahari (who are brothers, in case anyone's wondering). Unsurprisingly, there's rather a lot more in this version :) I bought the book with a fairly open mind, and as you'll see, I was quite impressed...

For the purposes of this review, I'll use the "Nutshell" to mean "C# 3.0 in a Nutshell". It'll just make life a bit easier.

Scope

Nutshell covers:

C# 1.0 to 3.0 (i.e. it's "from scratch")
Core framework (serialization, assemblies, IO, strings, regex, reflection, threading etc)
LINQ to XML
A bit of LINQ to SQL while discussing LINQ in general

It explicitly doesn't try to be a "one stop shop for every .NET technology". You won't find much about WinForms, WPF, WCF, ASP.NET etc - to which my reaction is "hoorah!". I've probably said it before on this blog, but if you're going to use any of those technologies in any depth, you really need to study that topic in isolation. One chapter in a bigger book just isn't going to cut it.

That's the scope of the book. The scope of my review is slightly more limited. I've read the C# stuff reasonably closely, and dipped into some of the framework aspects - particularly those I'm fairly knowledgeable about. The idea was to judge the accuracy and depth of coverage, which would be hard to do for topics which I'm relatively inexperienced in.

Format and style

Nutshell is a reference book which goes to some lengths to be readable in a "cover to cover" style. It's worth mentioning the contrast here with C# in Depth, which is a "cover to cover" book which attempts to be useful as a reference too. I'd expect the index of Nutshell to be used much more than the index of C# in Depth, for example - but both books can be used in either way.

As an example of the difference in style, each section of Nutshell stands on its own: there's little in the way of segues from one section to the next. That's not to say that there are no segues, or indeed that there's no flow: the order in which topics are introduced is pretty logical and sometimes there's an explicit "having looked at X we'll now look at Y" - but it feels to me like there's less attempt to keep the reader going. That's absolutely right for a reference book, and it doesn't prevent the book from being read from cover to cover - it just doesn't particularly encourage it.

There are lots of little callout notes, both in terms of "look here for more depth" and "be careful - here be dragons". These are very welcome, and call attention to a lot of important points.

The layout is perfectly pleasant, in a "normal book" kind of way - it's neither the alternating text/code/text/code style of the King/Eckel book, nor the "pictures everywhere" Head First format. In that sense it's reasonably close to C# in Depth, although it uses comments instead of arrows for annotations. The physical format is slightly shorter and narrower than most technical books. This gives a different feeling which is hard to characterize somehow, but definitely present.

Accuracy and Depth

The main problem I had with Head First C# was the inaccuracies (which, I have to stress, are hopefully going to be fixed to a large extent in a future printing). While there are inaccuracies in Nutshell, they are generally fewer and further between, and less important. In short, I'm certainly not worried about developers learning bad habits and incorrect truths from Nutshell. Again, I've sent my list of potential corrections to the authors, who have been very receptive. (It's also worth being skeptical about some of the errata which have been submitted - I've taken issue with several of them.)

The level of depth is very well chosen, given the scope of the book. As examples, the threading section goes into the memory model and the string section talks a bit about surrogates. It would be nice to see a little bit more discussion about internationalisation (with reference to the Turkey test, for example) as well as more details of the differences between decimal and float/double - but these are all a matter of personal preference. By way of recommendation, I'd say that if every professional developer working in .NET knew and applied the contents of Nutshell, we'd be in a far better state as a development community and industry.

The coverage of C# is very good in terms of what it does - again, appropriate for a reference work. I'd like to think that C# in Depth goes into more detail of how and why the language is designed that way, because that's a large part of the book's raison d'être. It would be a pretty sad indictment of C# in Depth if Nutshell were a complete superset of its material, after all.

Competitive Analysis

So, why would you buy one book and not the other? Or should you buy both? Well...

Nutshell covers C# 1 as well as 2 and 3. The 3.0 features are clearly labelled, and there's an overview page of what's new for C# 3.0 - but if you know C# 1 and just want to learn what's in 2 and 3, C# in Depth will take you on that path more smoothly. On the other hand, if you want to look up aspects of C# 1 for reference, Nutshell is exactly what you need. I wouldn't really recommend either of them to learn C# from scratch - if you know Java to start with, then Nutshell might be okay, but frankly getting a "basics" tutorial style book is a better starting point.
Nutshell covers the .NET framework as well as the language. C# in Depth looks at LINQ to Objects, rushes through LINQ to SQL/XML/DataSet, and has a bit of a look at generic collections - it's not in the same league on this front, basically.
Nutshell aims to be a reference book, C# in Depth aims to be a teaching book. Both work to a pretty reasonable extent at doing the reverse.

To restate this in terms of people:

If you're an existing C# 1 developer (or C# 2 wanting more depth) who wants to learn C# 2 and 3 in great detail without wading through a lot of stuff you already know, get C# in Depth.
If you want a C# and .NET reference book, get Nutshell.
If you want to learn C# from scratch, buy a "tutorial" book about C# before getting either Nutshell or C# in Depth.

Clearly Nutshell and C# in Depth are in competition: there will be plenty of people who only want to buy one of them, and which one will be more appropriate for them will depend on the individual's needs. However, I believe there are actually more developers who would benefit greatly from having both books. I'm certainly pleased to have Nutshell on my desk (and indeed it answered a colleague's question just this morning) - and I hope the Albahari brothers will likewise gain something from reading C# in Depth.

Conclusion

C# 3.0 in a Nutshell is really good, and will benefit many developers. It doesn't make me feel I've in any way wasted my time in writing C# in Depth, and the two make good companion books, even though the material is clearly overlapping. Obviously I'd like all my readers to buy C# in Depth in preference if you can only buy one - but it really does make sense to have both.

Book review: Head First C#

skeet — Fri, 21 Mar 2008 08:30:00 GMT

Important "versioning" note

This review tackles the first printing, from November 2007. Since then, the book has undergone more printings, with errata being fixed in each printing. I believe most or possibly all of the errors listed below are now fixed - although I don't yet know whether there are more lurking. I have a recent (late 2009) printing which I intend to review when I have the time - which means it's likely to be in 2010Q2 at the earliest, and more likely later. I don't know how much editing has been done in terms of best/bad practice. I have left the review as I originally wrote it, as it is a fair (to my mind) representation of that first printing. (This is something to bear in mind with all reviews, mind you - check when they are written, and ideally which version they're written about.) I'm reluctant to go as far as recommending the latest printing without actually reading it, but I'm fairly confident it's a lot better than the first printing.

You should also bear in mind that many C# books - including Head First C#, the Essential C# book referenced in the review and my own book - are currently being revised for C# 4. If the HFC# 4 book comes out before I've had time to review the latest printing of the previous edition, I will probably go straight for that instead.

Resources

Introduction

This is a tough review to write. We already know I'm biased due to being in some way in competition with Andrew Stellman and Jennifer Greene (the authors), but I'm also not a huge fan of the Head First series in general. It doesn't coincide with how I like to learn. I feel patronised by the pictures and crosswords rather than drawn into them, etc. However, I'm very aware that it's really popular - lots of people swear by it, and I know that my own tastes are far from that of the majority. There's also the fact that Head First C# really isn't aimed at me at all - it's aimed at people who don't know C# to start with.

Funnily enough, that's why I really, really wanted to like the book. It's not actually competing with C# in Depth except for readers who have no idea what either book is like. I can't imagine many people being in the situation where both books would be appropriate for them. I do want to find a good book for someone to learn C# from though, from scratch. My own book is completely unsuitable for that purpose. Essential C# by Mark Michaelis is my current favourite, I think - although I confess to not having read it all. It also doesn't cover C# 3 - although I'm not sure whether I'd actually want to cover C# 3 for a reader who doesn't know 1 or 2.

Anyway, I had hoped that Head First C# (HFC# from now on) would become a good recommendation - and part of this is because Andrew and Jennifer have certainly been very friendly on the blog and email. I don't like being nasty, and I know how I'd feel reading a review like this of my book. Unfortunately, it falls a long way short of being worthy of recommendation, and I can't really find a way of hiding that.

I "read" the whole book today. Now, it's over 700 pages and I've been at work, so clearly I haven't read every word of every page. I have mostly skimmed the code examples - vital for learning, I'll gladly admit, but not hugely necessary for getting the gist of the book. I skimmed over the graphics section particularly quickly, being more interested in the language and core library elements than UI topics. With that in mind, let's look at what I did and didn't like:

The Good

This is going to be a broadly negative review, but it's not like the book is without merit. Here's what I liked:

Many of the examples were very nicely chosen. I liked the party organizer (chapter 5) and the room topology (chapter 7) ones in particular.
You really do get to create some nifty WinForms applications. I wouldn't like to claim you really understand everything about them by the end of it, but I can see how they're engaging.
Annotations in listings are a good thing in general, and I do like the handwritten feel of them.
Q&A is a good idea for a book like this. Predicting natural questions is an important part of
After a slightly scary chapter 1 (building an addressbook using a database without actually knowing any C#) it does start from the real beginning, to some extent.
The pictures in this book were actually not annoying, to my surprise. Some were even endearing. Even to me.
Apparently other people really like this book. It's got loads of 5-star reviews on Amazon, and apparently it's been selling fantastically well. From the posts in the book's forum, people are really getting engaged, which can only be a good thing.

The Bad...

Formatting

I know the Head First series is all about its wacky style, etc - but I still find it can take a while to work out how you're meant to navigate through the page. Often bits of the page do require a certain order, but that order isn't always obvious.

My main problem with the formatting wasn't nearly as general as that though, and I have to admit it's a bit obsessive-compulsive. It's the quotes in the code. They're not straight. I've never seen an IDE which tries to work out "curly quotes" in code, and I hope I never do. When you're used to seeing code in a real IDE, seeing curly quotes just looks wrong. It's jarring and distracts from the business of learning.

Oh, and K&R bracing sucks. I know it makes the book shorter, but it makes it harder to read too. Just a personal opinion, of course :) (Having said which, the bracing style is inconsistent through the book anyway.)

"Top-down" learning

I'm unashamedly a "bottom-up" person when it comes to learning. I like to get hold of several small building blocks, understand them to a significant degree, and then see what happens when I put them together. This book prefers the "show it all and explain some bits as we go along" approach, reasonably frequently mentioning how awful it is that most technical books try to start with console applications which don't need lots of libraries before you even know what a library is.

I suspect this top-down way does indeed get people going much more quickly than my preferred style. (Remember, this is my preferred reading style, not just writing style. It's no coincidence that I happen to write like I read though.) However, I believe there's a great danger of people ending up as cargo-cult programmers. (I know I refer to that blog entry a lot. It happens to rock, and be relevant to much of why I write how/what I write.)

It's true that top-down learning gets you doing flashy stuff more quickly than bottom-up. Whether that's more fun or not depends on what appeals to you - I get a great sense of joy from thinking about a difficult topic and gradually understanding it, even if I have nothing to show for it beyond console apps which do little but sort numbers etc.

It feels like there ought to be a middle way, but I've no idea what it is yet. The "show something cool in chapter 1 and then go back over the details" approach favoured by the vast majority of technical books (including mine, to some extent) isn't what I'm thinking of. Definitely something to think about there.

Incompleteness

I hadn't expected this book to be in great depth, despite the quote on the back cover: "If you want to learn C# in depth and have fun doing it, this is THE book for you." I'd expected a bit more than this, however.

When I said earlier on that HFC# wasn't competing with C# in Depth, I mentioned audiences. There's something to be said about material as well though. Let's look at the bulk of my book - chapters 3-11, which deal with the new language features from C# 2 and 3. Here's how much is covered in HFC#:

Generics: generic collections get mentioned, but there's no real explanation of how you'd write your own generic types. Generic methods aren't mentioned. Type constraints, default(...), variance (or lack thereof), type inference - all absent.
Nullable types: not mentioned as far as I can see, including an absence of the null-coalescing operator.
Delegates: there's a chapter on delegates which deals entirely with events and callbacks. No mention of their use in LINQ. No use of method group conversions, anonymous methods or support for variance. (In fact, there are some false claims around that, saying that the signature of an event handler has to match the delegate type exactly.)
Iterator blocks: IEnumerable<T> is mentioned, but IEnumerator<T> is never shown as far as I remember, and iterator blocks certainly aren't shown. It mentions that you could implement IEnumerable<T> yourself, but doesn't give any hints as to how, or what would be required.
Partial types: covered, albeit only mentioning classes. No sign of partial methods.
Static classes: covered to some extent, but without explaining that they prevent you from attempting to use the class inappropriately, or other details like the absence of constructors (not even a default one).
Separate getter/setter access: covered
Namespace aliases: not covered
Pragma directives: not covered
Fixed size buffers: not covered
InternalsVisibleTo: not covered (not really a language feature though)
Automatically implemented properties: covered, but without mentioning (AFAICR) that a hidden backing field is generated for you
Implicit typing: one call-out and a somewhat inaccurate Q&A
Object/collection initializers: covered, but without noting that you can remove the brackets from parameterless constructor calls
Implicitly typed arrays: not covered
Anonymous types: mentioned in a single annotation, but inaccurately. Used in a few query expressions.
Lambda expressions: not mentioned (in a book which "covers" C# 3.0. Wow.)
Expression trees: not mentioned
Changes to type inference/overloading: hard to explain a change to something which isn't covered to start with
Extension methods: covered
Query expressions: covered to a very limited extent. No explanation of query translation. No explanation of query continuations (although grouping is always shown with continuations). No sign of multiple "from" statements or "join into".

See why I don't think our books are really competing? Now, a lot of this really is absolutely fine. The details of generics don't really belong in an introductory text - although some more information would have been welcome. Pragmas and fixed size buffers would have been completely out of place. Would it be too much to ask for some discussion of anonymous methods and lambda expressions though, particularly as lambda expressions really do make LINQ possible?

Maybe I'm being too harsh, looking at just C# 2 and 3 features (which is pretty much all my book does). Here are some things which would have counted as being missing had the book been published in 2002:

typeof(...)
Casting ("as" doesn't count as a cast in my view - it's an operator)
lock
volatile
Explicit interface implementation
The conditional operator (x ? y : z)
Hiding members with "new" instead of "override"
readonly
The sealed modifier on methods (not just classes)
ref/out/params modifiers for parameters
continue, goto, and break (break is mentioned for switch/case, but only there)

Maybe going into the memory model would have been a bit much (without which volatile would be pretty pointless) but not to even mention threading (and lock) feels a little worrying - especially as Application.DoEvents is abused instead. Explicit interface implementation is relatively obscure - but readonly fields? typeof(...)?

Fine, it's an introductory text - but that means it's a bad idea to talk about "mastering" LINQ and claiming that "by the time you're through you'll be a proficient C# programmer, designing and coding large-scale applications". Those quotes probably aren't the authors' fault, to be honest - and marketing has a way of exaggerating things, as we all know. But no-one should be in any doubt that this is far from a complete guide to C#.

Errors (please see update at the end of the post, and note at top)

This is by far my biggest gripe with the book. It's probably coloured the whole review - things which I could have forgiven otherwise have been judged more harshly than they would have been if the entire book had been accurate. Accuracy is what I demand from a book above all else, partly because it's not obvious to the reader when it's absent. No-one could reasonably read the book without realising that they're getting a top-down approach, or what the formatting is like, or that there are going to be crosswords etc. However, a reader has little to benchmark accuracy against unless the book is internally consistent.

Now, I'm unfortunate enough to have the first edition (November 2007). The book is currently undergoing its third printing, i.e. it's had two rounds of corrections. These are listed in the errata and I've tried to take them into account - although there's no way that a carefully reviewed and edited book should need that many corrections in such a short space of time. I will concede that a Head First book is likely to be much harder to get right than a "normal" book though, due to all the funky formatting.

Typos don't worry me too much. It's core technical errors which really bother me. It's almost as if someone had taken my list of classic "myths" and decided to taunt me. I half expected "objects are passed by reference" to be in there - but as ref/out parameters aren't covered at all, it's not. Here are some of the worst/most amusing culprits though:

Claiming that string is a value type (in several places). Oh, and object, once.
Claiming that the range of sbyte is -127 to 128 (instead of -128 to 127). Same kind of mistake with short.
Constantly using field and property as if they were interchangable. They're not, they're really, really not. Just because they're used in a similar way doesn't mean you can be this loose with the terminology.
Claiming that C# "marks objects for garbage collection". In fact, for the first 6/7ths of the book there's a strong implication that garbage collection is done in a deterministic way; that objects are immediately collected when the last reference is lost. We do eventually find out that it's non-deterministic (although that explanation is also flawed) but by then it may well be too later for the reader. More on this in a minute.
Claiming that methods and statements always have to live in classes. Funny how structs can have behaviour too...
Claiming that "objects are variables" (in a heading, no less). I know from experience that trying to accurately describe the interplay between objects, variables, and their values is tricky - but even so...
Writing a hex dump utility using StreamReader - broken by definition, given that hex dump tools are used to show the binary contents of files, and StreamReader is meant to read text, decoding it as it goes.
Claiming that structs always live on the stack.
Expanding WPF as "Windows Presentation Framework"

These are all errors which have made it through not just technical review, but two rounds of post-publication editing. It's possible that some of the errors on my list of about 60 (ignoring typos for the most part) are in the errata and I missed them (I did try to check them all) - but really, I shouldn't have been able to find that many in the first place, even if they have been corrected. I'm worried if a C# book author believes that a char has 256 possible values, for instance. I know that the author is wrong, and to check the errata (this one has indeed been fixed) but I suspect many first edition readers will never look at the errata.

Now, there are errors and there are bad practices...

Bad practice through example

I know we don't end up writing production code as book examples. Indeed, Eric mentioned this in chapter 1, where I'd left a few things out which I would normally consider as best practice: making a type sealed, making fields readonly etc. I left extra modifiers out for simplicity. I can understand that. I can also understand using public fields until properties have been explained but:

There's no reason to use poorly named variables/parameters, including Pascal-cased local variables
Writing loops like for (int i=1; i <= 10; i++) instead of the more idiomatic for (int i=0; i < 10; i++). C# is 0-based in many ways, but often the authors seemed to really wish it were 1-based.
Continuing to use public fields even after explaining how they're not really a good idea. (Well, sort of explaining that. There's a frequent implication that they're not so bad if other classes really need to be able to access your data. It's a very long way from my preferred policy of no non-private variables whatsoever.)
String concatenation in loops with nary a mention of StringBuilder
Bizarre combination of "is" and "as", using "as" to perform the conversion instead of casting. If you're going to use "as", do it up front and compare with null to start with...
Advising leaving out braces for single line for/if statements. The code which is left in these examples is unreadable, IMO. You have to really concentrate to see what's in and what's out.
Advising to stick with the absolutely abhorrent "convention" (aka laziness, and leaving things as VS creates them) of naming event handlers with things like button1_Click. No. Name methods with what they do, then the event hookup code will make it obvious - and it makes it clearer where you can reuse a single method for multiple events.
Repeatedly declaring enums within classes as if you couldn't write them as top-level types. Oh, and messing up the naming conventions there, too.
Showing a mutable struct without explaining that this should always be avoided is a bad idea.

I could go on. I've got pages of notes about this kind of thing (and this is only after owning the book for less than a day, don't forget) but I think you get the message. Note: some of these things are definitely a matter of opinion, such as bracing style. Some other things are so widely regarded as a bad idea that I can't see much defence for them.

Examples matter. I don't expect to see production code, and I understand that sometimes for teaching purposes best practices will take second place - but where it wouldn't hurt to use best practice, please do!

Likewise telling the truth from the start matters. It's very hard to correct bad habits and incorrect impressions. If you state that "When we set lucky (a variable) to null, it's no longer pointing at its object, so it gets garbage collected" then people will not only be potentially confused about whether it's the variable or the object which gets garbage collected, but they'll get the impression that it's garbage collected immediately. Waiting 476 pages to correct that impression is a bad idea.

Public fields are another example. I've mentioned that I can see their usefulness before we've encountered properties - but even so, surely it would have been worth explaining immediately that we're going to hide them as soon as possible.

Conclusion

You may have gathered by now that I'm not a fan of the book ;) I suspect a lot of this review has come off as a rant, which is a pity. That tends to happen when I get on my technical high horse, which I guess I've done here. The fact is, I've spent a lot of today feeling deeply saddened. I wouldn't be surprised to find that this is the best-selling C# book of 2008 - which means we'll get a lot more people on the newsgroup with some very odd ideas about how C# works. That's the trouble - I've seen what happens when people are fed the "structs live on the stack" myth. I've seen how easily people can believe that strings are value types, and that it doesn't really matter if you use a StreamReader for binary data and then cast chars to bytes. It causes trouble.

I'm reasonably sure the world could do with a good introductory book on C#. HFC# has convinced me that such a book could be fun and have pretty pictures. But HFC# isn't quite it. (And no, I don't plan on writing it either.)

Feedback

I gave an advance copy of this review to Andrew, who has replied remarkably politely and pleasantly (and quickly). He's a true gent, giving a really thorough reply when I suspect most authors (perhaps including myself) would either have given short shrift to a review like this, or possibly ignored it competely and hoped it would go away.

He believes I was looking too much for a complete reference rather than an introductory text. I would say I wasn't looking for completeness, but a better judge of what should be in a C# book (I'd have preferred ref/out to be covered, but would be happy to lose the section on GDI+ double buffering, for instance). I specifically don't want an actual reference book if I'm going to recommend it to people to learn from - but I may be biased towards a reference style as that's what I personally tend to learn from.

It was really the errors that affected this review more than anything though, and while a very few of them could be debated (whether an implicit reference conversion to a base class counts as upcasting, for instance - I'd only include explicit upcasting) many others are undeniable and really shouldn't have made it through the review process. It's possible that I'll come back to HFC# in a year's time and be more impressed by it, but I suspect the aversion to errors will overcome any mellowing towards the style :(

Update (22nd March 2008)

Andrew continues to amaze me in terms of taking this review in his stride. He's now looking through the errors I found, and many should be fixed in the next printing. Bear in mind that without a lot of the errors, I would have had a more positive view from the start.

In short, I'm still not quite convinced I'd recommend the book, but my opinion has certainly mellowed (anticipating the error fixing, of course).

Book review/preview: "C# Query Expressions And Supporting Features in C# 3.0" (Eckel/King)

skeet — Mon, 17 Mar 2008 00:40:04 GMT

Introduction

Let me make one thing very clear before anything else: this is a preview. Bruce Eckel has made the preview of what appears to be part of a bigger book available free from his website. The book is by Bruce Eckel and Jamie King, and the preview available (1.0 at the time of writing) covers the following topics:

Extension methods
Implicitly typed local variables
Automatic properties
Implicitly-typed arrays
Object initializers
Collection initializers
Anonymous types
Lambda expressions
Query expression translation

For obvious reasons, this had me slightly worried when I first looked at it - it's clearly a reasonably direct competitor to C# in Depth. There's not a lot of C# 3 which isn't covered here. I can only think of these things off-hand:

Expression trees
Object initializers setting properties of embedded objects
New type inference rules
New overload resolution rules

I was surprised to see expression trees not get even a mention. I'm sure they'll be covered elsewhere in the full book, but I personally think it's worth introducing them at the around same time as lambda expressions. (It would be odd for me to have any other view, given the location in C# in Depth!) I don't know whether the new rules for type inference and overload resolution will be covered elsewhere. If they're going to be covered but the authors haven't done the writing yet, we should all feel sympathy for them. That section (9.4) was the hardest one in the whole book for me. It may be possible to describe all of the rules in a way which doesn't make both reader and writer want to tear their hair out, but I have yet to see it.

I don't know exactly what the bigger book will cover, or how it will be published, or whether it will be available in preview form, etc. From here on in, when I say "the book" I mean "the preview bit".

Format

After the TOC and introductory material, the book basically consists of 4 things:

Headings (occasional)
Explanatory text
Code
Exercises

There are no diagrams or tables as far as I can see. The main body of the book (P7-137) sets exercises quite frequently (there are 54 of them), and the answers form P138-233, including brief explanations.

The code is always complete, including using directives, a Main method (for non-library classes) and output. A lot of the time the code essentially forms unit tests to demonstrate the features (a technique we used in Groovy in Action, by the way). The authors have their own build system which not only runs the tests, but also allows comments to express pieces of code which shouldn't compile. The output is also checked, i.e. that running the code produces the output in the book.

There are pros and cons to this approach. For those who haven't read any of my book (what are you waiting for? The first chapter is free!) I personally use a tool I wrote called "Snippy" which allows me to include short but complete examples without using directives and Main declarations appearing everywhere. My comments on this book's approach:

I'd be surprised to see any misleading/broken examples. (There's one piece of code which doesn't go quite as far as I believe it should, but that's a different matter.)
It encourages unit testing.
It leads to longer code with repetition (Main etc).
The build system leads to non-standard comments, like //c! to indicate a non-compiling line and //e! to indicate where an exception should be thrown.
There's a little too much text dealing with the build system - it's distracting

The "long code" issue has been dealt with by squeezing a lot of code into short spaces - K&R bracing and very little whitespace. Personally I find this really quite tricky to read, to the extent that I ended up skipping a lot of the code examples. I've tried to keep all my code examples pretty short, and none of them are over a page. (That was an unstated goal at the start of the project, in fact.)

Now, how much code do you like to see in a book? That's very much a personal decision. I happen to like quite a lot of explanatory text - so that's how I write, too. In this book I reckon (and it's only a complete guess) about 50% of the book is code, 35% is prose and 15% is exercise. This quite possibly pose a challenge for me as a reader if I didn't already know the topic. However, for other readers it's probably spot on.

What this book doesn't have (fortunately) is lots of examples which go on for pages and pages, producing a complete application with little explanation. I've seen that too often - and a lot of the code simply doesn't teach me anything. I've never particularly liked the "build a complete application" approach to books, partly because it doesn't actually mean that all the bases are covered (you don't see every issue in every app) and it does mean there's a lot of turn-the-handle code which isn't relevant to the topic being taught. It can be a useful technique in some situations, but I like it when irrelevant code is omitted (and is just available for download).

The other personal question is whether or not you like exercises. I certainly believe in trying out new things as you read about them, but exercises don't really fill that need in an ideal way for me. I like to try to apply a new technique to an existing bit of code, or an existing database for instance - and obviously the author has no way of knowing that. Now, that only says something about me, not about the value of exercises. This book has been used for teaching in a university, and I suspect the exercises have been appropriate in that setting. Note for future consideration (and reader feedback): should I include exercises in any future books I might write? Should I create some for the C# in Depth web site?

Style

(Some of this might reasonably count as format as well - it's a blurry line.)

I have a consciously "light" style. I write in the first person and try to include opinion and the occasional joke or at least lighthearted comment. (Footnote 1 in chapter 3 is my favourite, for reference.)

Eckel and King's book is more like a textbook. The authors haven't allowed their personalities to come through in the text at all - and it's clearly a deliberate decision. Good or bad? Hard to say - it depends on the context. The word "textbook" is the key here, for me - I can't remember textbooks having any personality when I was a student, so if they're going for that market it's spot on. In the "professional developer" market it may have a harder time. Again, personally I'm a fan of a bit of personality peeping through the text - although it has to be firmly controlled, and it's better to err on the side of caution. I've read some books which seem to be all about the author's personality, without letting the subject matter have a look-in.

I do think more headings (of varying sizes, if you see what I mean) and the occasional diagram would be helpful, though. It's a pretty unrelenting code-text-code-text-exercise-code-text-code-text mix. The code is all just "there" with no headings, nothing to visually break things up. (It's not actually run-on with the text - it's clear where text stops and code starts, and there's even a helpful vertical line down the side of the code - it's just that there's nothing to make you take a mental breath.) This could be due to it being a preview - it's possible that more formatting will occur later on. If that wasn't the plan, I'd encourage the authors to at least consider it. (Wow, see how easy it is to slip into arrogance? Must make a memo to give Joel Spolsky some notes on writing later ;)

Content

The content is pretty full-on, and very language-focused. As an example, I suspect few books on C# 3 will go into any detail about transparent identifiers in query expressions. In my book I explain them for one particular clause ("let") and then just mention when the compiler will introduce one for other clauses. Eckel and King's book gives full exampes of translation for all the clauses available, as far as I can tell.

That's just an example - and possibly an extreme one - but this book does go into a reasonable amount of depth when it comes to the facts. (There were also two items I wasn't aware of: the option of explicitly stating that an ordering is ascending, and the ability to create "extension delegates". They're not huge omissions in my text (and at least I've now got notes for them), but the fact that I missed them and these guys didn't is (to me) an indication of their thoroughness.

Now, having dealt with the plain facts, there's not a lot of opinion in the book - pieces of text which encourage the reader to think about why C# has changed the way it has, or the best way to take advantage of those changes. Again, this is a valid approach for a textbook - especially one used in conjunction with a course where the lecturer can talk about these things - but I suspect the non-academic market likes guidance.

The accuracy level seemed pretty high to me. Not perfect, but then I don't expect mine is either, even with Eric's thorough eye. In everyone's interests, I've mailed the authors my specific comments and nitpicks - as the book is still at a preview stage, corrections can be made relatively easily, I expect.

Conclusion

Obviously I can only comment on the book as I've seen it so far - I've no idea whether the other chapters will be more framework-focused. However, it's good to see another book that tries to "go deep" like mine does. While this clearly makes it competition in many ways, I think we're aiming at different audiences. If I'm right in my assumption that this is trying to be a textbook, there may be little overlap in potential market. (I suspect the same will be true of Head First C#, which is likely to be my next review - but for the opposite reason. I suspect I'll find that HFC# is more aimed at beginners - something that certainly couldn't be said of this book or mine.)

Overall this is a very solid text, in many senses. It's not the easiest book to follow due to its style, but it's detailed and accurate. Given a choice between the latter and the former, I'd always choose the latter for anything I'd want to refer back to - and this book certainly counts as a good reference for query expressions. Obviously I'm hoping people find my style appealing and that I'm detailed and accurate, but I can't give that judgement.

As a final word - if you haven't downloaded it yet, why not? It's a totally free download of only just over a meg. I don't think I even had to register anywhere to get it. Reading other work is useful for me as a writer, but there's no need for you to trust my judgement, nor indeed would it be wise to do so. If you missed it before, I'll even save you scrolling up for the download link.

I'd be interested to hear whether your opinions coincide with mine. If you've read my book and can compare and contrast, so much the better. I've let the authors know that this review is coming, so I suspect they'll be checking here for feedback. (They'd be foolish not to, and I have no reason to believe they're fools.)