Jon Skeet: Coding Blog : Book reviews

Non-review: The Data Access Handbook by John Goodson and Robert A. Steward

skeet — Fri, 10 Jul 2009 16:19:21 GMT

A while ago I agreed to write a review of this book (which the publisher sent me a free copy of) but I haven't had time to read it fully yet. I've been skimming through the first couple of chapters though, and it's pretty interesting. I'll post a full review when I have more time (along with reviews of CLR via C# and a bunch of other books) but I thought it would be at least worth mentioning the book in advance.

It's really a performance book - as far as I can tell that's its sole purpose (and I'm lumping scalability in with performance) which is fine. It covers some generalities and then splits by client technology (ODBC, JDBC, .NET) for the middle section. The final chapters are general-purpose again.

I'm loathe to say much more about it yet, having only read a small amount - but I'll definitely be reading the rest. It's unlikely to be particularly useful in my current job, but you never know - one day I may be talking to a regular SQL database again :)

Links:

Book Review: C# 2008 and 2005 Threaded Programming: Beginner's Guide by Gastón Hillar

skeet — Mon, 16 Mar 2009 17:21:00 GMT

Update (19th March 2009)

Debate around this review is getting heated. I stand by all the points I make about the text, but I'd like to clarify a few things:

If there are any ad hominem comments in the review against the author, please ignore them. I'm going to try to weed out any that I find, but if you spot one, please let me know and then ignore it. I feel very strongly that a review should be about the text of a book, not about its author. The text is what will inform the reader, not the author's other work. I'm aware that Gastón Hillar has written many other books, and is generally well-regarded (as far as I can tell, anyway). That neither helps nor hinders the text. The same goes for me and the review, of course. Whether you know me or not, whether you've read anything else I've written or not, the review should stand on its own merits. This is not a popularity contest - it's a discussion about a technical book.
The impression I've given in the review is almost entirely negative. This is because that's the impression I received as a reader interested in accuracy and best practices. That does not mean that the book is entirely inaccurate - far from it. There are plenty of aspects where I have no particular issues with the accuracy. (The code style is more uniformly disagreeable to me, but that's a subjective matter.) However, there is enough inaccuracy (and bad practice, in my view - somewhat subjective, but less so than the code style) to make that the dominant impression left with me, alongside my surprise that there's no proper discussion of locking. As an analogy, imagine you go to a choral concert. Suppose the sopranos, altos and tenors are all perfectly in tune, but the basses are out of key the whole time. In some senses the concert would be 75% accurate - but the 25% inaccuracy would be enough to ruin it. So it is with technical books (not just this one) - it only takes a relatively small degree of inaccuracy to make the difference between a good book and a bad one. The bottom line is: even I don't think everything or even most of what's written in the book is wrong; there are enough problems to make me dislike it though.
I've made a few minor edits to the review just now, to address a few comments made so far. If some of the comments appear to be odd, that may be why!

Resources

Publisher's page (Packt) - this is the cheapest way to buy the book as far as I can see
Sample code (49MB download! Mostly because it contains bin/obj directories for all solutions...)
Amazon or Barnes and Noble links if you don't want to buy it directly
John Mueller's review - a much more positive review than this one, which may prove an interesting counterbalance for readers. (Thanks to Erik for pointing out John's review in the comments.)

Disclaimer

This book doesn't really compete with C# in Depth, but obviously the very fact that it's another book about C# at all means I'm probably not entirely unbiased. Arguably it also "competes" with my own (somewhat out of date now) threading article, although that's not a monetary venture for me. I should also point out that my copy was sent to me for free, specifically for review, by Packt Publishing.

Audience and content

The book claims that "Where you are a beginner to working with threads or an old hand who is looking for a reference, this book should be on your desk." In practice, I don't think it's really suitable as a reference. The kind of information you really want as a reference is hard to find amidst the bulk of the book, which is on-going examples. For the rest of this review I'll regard the intended audience as just beginners.

The first chapter (out of 12; at 388 pages one of the nice things about this books it that it's relatively slim) is introductory material about threads and processes, and why concurrency is important in the first place. After this one code-free chapter, the rest of the book is all example-based. The pattern goes something like this:

Give rough idea of what we're building
Create first version of the code
Explain what it does and why it may not be ideal
Improve it
Explain how the improvements work
Move to next example or add new major feature

That sounds all very well, but I'll get to my issues with it in a minute. Although the examples are constantly evolving, they essentially break down into these applications:

"Code cracking" (brute-forcing a 4 character code)
"Encrypting" SMS messages (not real encryption - no key - but a general CPU-intensive transformation)
Image processing to find and highlight "old stars" in NASA images
"Encrypting" several files
More image processing - adjusting the brightness of a large image and thumbnailing it

These are all Windows Forms applications, and are frankly pretty similar, all basically dealing with simple, embarrassingly parallel tasks. That's not to say Hillar doesn't get a fair set of different techniques and lessons out of them:

Keeping the UI thread free (and seeing what happens when you don't)
Tips for debugging multi-threaded apps in Visual Studio
Showing the performance for individual processes using Task Manager and Windows Explorer
Using BackgroundWorker to update the UI
Queuing tasks in the system thread pool
Creating new threads explicitly
Using Control.Invoke/BeginInvoke to update the UI (although this comes very late in the book - chapter 10 out of 12)
Keeping tasks independent
Noting that sharing data between threads is difficult - but coming to the wrong conclusions (more later)
Using the Timer component (just the WinForms timer; not System.Threading.Timer, System.Web.UI.Timer or System.Timers.Timer) - although later on he uses a BackgroundWorker for a task much more suitable for a Timer.
A bit of OO design, although in a pretty botched way - the idea of having a general-purpose "parallel algorithm" class and a "parallel algorithm piece" class is reasonable, but it isn't handled nearly as well as it might be
Fairly disastrous advice (IMO) about both I/O and the GC
Exception "handling" (where "swallowing exceptions and just reporting them with Debug.Print" counts as "handling" apparently)
Parallel Extensions from .NET 4.0, with both PLINQ and TPL

Unfortunately, this misses out some of the most important concepts in parallelism on .NET. Hillar frequently mentions locking, but only ever in a "we're avoiding doing it" way. I find it absolutely incredible that a book on multi-threading in C# doesn't even mention the "lock" keyword. Okay, it's nice to be able to split tasks up completely independently where possible, but in the real world you sometimes have to use shared mutable state (or at least, it's often the simplest approach).

When I first got the book, I looked up several entries in the index to see how they'd be handled. I was shocked to find that none of these have an index entry:

lock
volatile
memory model
Monitor
Wait or Pulse
BeginInvoke or Invoke
double-checked locking
mutable or immutable

The concept of accessing state from multiple threads is glossed over for the entirety of the book. Basically whenever multiple threads want to make their results available, they put them in different elements of an array or list. There's an assumption that if you read from that array/list in a different thread, it's all okay. Likewise there's an assumption that it's appropriate to read integer variables written to in one thread from another thread without any locking, volatility or use of the Interlocked class. I'll come back to this topic when I tackle accuracy later on.

Style

This is a very informal book: something I have no problem with. English clearly isn't the author's first language, and although I don't blame him for some of the clumsy wording in the book (e.g. "We will not leave behind the necessary pragmatism in order to improve performance within a reasonable developing time") I do wish the book's editorial team had done a better job in that respect. It's tricky with technical books: non-technical editors have good reason to be wary of going too far, as small changes in wording can have make a large difference semantically, but it does make a big difference to a book's readability when the language is clear and idiomatic. (As a side note, I feel incredibly fortunate to have English as my native tongue. I'm not fluent in any foreign languages, and I'm often amazed at how well others manage.)

There are other elements of the style of the book which I have much more of a problem with. The first is the way that the examples are handled. A very large proportion of the book is just lists of instructions: "add some using directives: <code>; add these variables: <code>; add this procedure: <code>; add another procedure <code>; add an event handler <code>" with just a sentence or two of explanation for each one as you go. There's much more explanation after all the code has been added, but the way that the code is given makes it very hard to see what's going on. We almost never get to see a whole class in one listing - it's always broken up into using directives, variables, individual methods etc. This may not be too bad if you're following along with the book at every single point, but it makes it very hard to just read. As a friend has commented, this content might work a lot better as a screencast, rather than as a book.

One detailed gripe: nearly every time a property is introduced, the author uses the phrase "we want to create a compact and reliable class" as a justification. There's no explanation, and quite often the properties are mutable for no good reason (when a genuinely reliable class in a multi-threaded setting would be immutable). After a while it made me want to grind my teeth every time I saw it.

The feeling is very much that of a Head First book, but one which doesn't work. For all my misgivings about Head First C# (which I believe is now very much better now that a large number of errors have been removed) the general style was very well handled. It's not my preferred style to start with (particularly focusing on large GUIs instead of short, complete console apps) but I rarely felt particularly lost in the listings - there was usually enough context to hold onto. Here, I feel there's very little context at all. If you accidentally miss out a step, you'll have a really hard time working out which one it is or what's wrong.

On top of this, there's the bizarre storyline "explaining" all the listings. Apparently you (the reader) originally started out cracking a code, then got hired by some other crackers, then the FBI, then NASA. We are told of FBI agents getting us capuccinos, the NASA CIO wanting you to use the Parallel Extensions CTP so that they can get free licences for Visual Studio 2010 and all kinds of other oddities. We are constantly bombarded with plaudits about our threading capabilities - by the last chapter we're regularly being called "experts" and "threading gurus" despite the fact that we wouldn't have a clue what was going on if someone presented us with some code using a "lock" statement. This is all patronising in the extreme - and again, Head First C# (and I suspect the rest of the Head First series) handles the "keep it informal but drive the topic forward" aspect a lot more successfully.

Finally, on the topic of style, I'd like to rant a bit about the coding style. It's awful. Really awful. I realise that coding standards are to some extent a personal thing, but I object to code like this:

Pseudo-Hungarian (the type which uses "o" as a prefix for almost any object; not the type Peter likes) and the nature of every variable (local, parameter or instance variable) makes for horrendous variable names such as "prloOutputCharLabels". It's not even consistent - variables added by the designer only get a type designation prefix (lbl, but, pic) but no nature prefix. Aargh.
Methods are frequently camel-cased instead of Pascal-cased, e.g. "showFishes" and "checkCodeChar". It's possible that this is only true for private methods - a very quick flick through doesn't reveal any public ones like this - but if so it's inconsistently applied as there are certainly Pascal-cased private methods too. Some public properties combine both annoyances so far, with names such as "poThread" and "piBegin".
Most (but not all) of the time Hillar declares all of a method's variables at the top, even if they're not used for a long time. This includes declarations of variables for use in loops. This took me right back to the 80s, writing ANSI C again. I believe that the ability to declare variables at the point of first use gives a significant improvement in readability. It's easier to see where a variable will be used if its scope is limited, for example.
Using directives aren't applied nearly thoroughly enough, leaving lots of explicit use of System.Diagnostics, System.Drawing, System.ComponentModel etc. Given the line length limitations in printed books, this is a real killer in terms of providing compact, readable code.
Speaking of line length limitations, it would be really useful to actually acknowledge them - if a comment is going to span two printed lines, starting just the first one with "//" and leaving the second indented but not really a comment isn't a good idea.

So, we've got code broken up into chunks which breaks the flow of the code, and I don't even like the style of the code. Still, I could live with that if it's good quality code...

Accuracy and best practices

I've already indicated one of the significant problems I have with the book in terms of content: its complete absence of discussion about shared data and locking. Yes, this is a beginner's book, and I wasn't expecting the level of detail on the memory model which is present in Joe Duffy's book (which I promise I'll review soon) - but I'd certainly prefer to err on the side of safety. The book regularly just accesses data on one thread having written it on another, with no locking, volatility or use of Interlocked. This isn't the sole bad practice, however, and it's not limited to stylistic choices either. In the course of the book, we are told all of the items below (and more). Italics indicate what the book claims; regular type indicates my response. These aren't verbatim quotes, but paraphrase:

Forcing garbage collection before starting a multi-threaded operation is a good idea. This is given as a sort of response to a screenshot of Process Explorer showing ugly memory usage. In fact, I can't reproduce the kind of nasty graph that's shown in the book, even with the code downloaded from the web site, but if I did see that there are definitely better ways of addressing it than forcing garbage collection. Disposing of Bitmaps appropriately would be a good start... as it is, each bitmap is going to hang around for at least one garbage collection cycle longer than it should, because we've got to wait for its finalizer to be executed. Making sure you dispose of objects appropriately is always a good idea - explicitly forcing the garbage collector is almost always a bad one. (Not absolutely always, but usually.)
WaitHandle.WaitAll has to run on an MTA thread - so let's just change the [STAThread] line above the Main method to [MTAThread], with no warning that it's a really bad idea to do that for Windows Forms. (Side-note: when trying to check that there really isn't a warning, I had to spend a long time finding the section. The index doesn't contain entries for MTAThread, STAThread, apartment, WaitHandle or WaitAll. In general the index could do with a lot of work. I'm painfully aware that indexing is a horrible task, but it's important.)
Application.DoEvents() is a way of letting the UI process events. This is true - it's also another really bad idea unless you absolutely have to use it. Re-entrancy is hard to debug - and not mentioned at all in the book, as far as I can tell.
Data streaming is wasteful, because two threads might both want to do I/O at the same time - it's a better idea for each thread to load all the data it needs to and then start processing it. This is stated in a context where streaming is ideal - each thread just needs to process every line in a file. (Each thread is asked to process a different file.) There's no dependency between the lines of the file. It's an absolute gift - the buffering and pre-fetch techniques of Windows would guess we needed the next block of data before we ask for it, so the disk would be seeking while we're encrypting, on each thread. At least, I strongly suspect it would - and I would profile the thing instead of just claiming that we've managed to avoid an I/O bottleneck by loading files in their entirety up-front. No mention is made of the fact that as soon as a bunch of big files are queued for encryption, you'll have a bunch of threads all trying to load everything before they bother starting to do anything. Avoiding I/O contention is a tricky topic, and it deserves better than a couple of misleading paragraphs with no attempt at explaining what the benefits of streaming the data would be.
The thread pool is used to queue threads with work to do. If there are already lots of threads busy, the new threads will wait until the old ones have finished. Note the use of "threads" here - not tasks to run on a pool of existing threads, but threads. This would make the thread pool pointless - what is never explained in the book is that creating threads is a relatively expensive business, and you don't want to do it repeatedly for short-lived tasks when you could instead create a pool of threads and reuse them to run several tasks. Once this purpose is clear, the notion of queuing threads becomes obviously wrong.
We can pass some state into the delegate used for work item queuing (or a ParameterizedThreadStart) and use that to give us some context. We need to cast that state to the relevant type before we can use it, because it's just typed as System.Object. So far so good - except most of the time, Hillar ends up passing into the work item the same reference which would be available as just "this" within the method itself. So we have code such as:

loPiece.poThread = new Thread(new ParameterizedThreadStart(loPiece.ThreadMethod));
...
loPiece.poThread.Start(loPiece);

The ThreadMethod method then duly casts its parameter to its own type and uses it. All of this is pointless, as the method doesn't need any parameters - it can just use "this" inside the method.
It's very important to initialize lists with the right capacity. Again, this isn't too bad as far as it goes - except that this micro-optimisation goes awry when he reads the TextBox.Lines property twice: once to work out the appropriate capacity and once to fill the list with initial data. Unfortunately the TextBox.Lines property has to take the existing text in the TextBox, split it (creating a bunch of substrings) and get the result into an array. This in turn means doing all the normal shenanigans associated with creating buffers which are bigger than you need, filling them, copying to a new buffer etc - exactly what we're trying to avoid! This "optimization" will usually cost time instead of saving it. It could be easily fixed by just fetching the array in one statement, then using the same array for both the count and the list population. In fact, if you just pass the array into the List<T> constructor, it will perform the optimization for you - it can detect that it's an ICollection<T> and use the Count property directly. Writing the simplest code actually ends up being optimal.
The above bullet point isn't going to dominate the performance of that example though - there's a potentially far worse effect due to the way the resulting "encrypted" string is broken up each time: using string concatenation in a loop. I guess we'd better hope there are no really long lines. If an author is going to give optimisation "tips" they need to be a lot more rigorous than this. Using string concatenation in a loop is probably the single best-known performance no-no in .NET. I was really shocked to see this in a book which is supposedly about making your code perform better. Now, it could be that string concatenation was used deliberately to slow things down - but in that case, why not highlight it? Drawing attention to intended optimizations gives the impression that the rest of the code is either optimized or has at least been written reasonably. If "bad" code is to be used for a specific purpose, that should be called out so that the reader won't go onto use the same kind of code in their own production apps (which really shouldn't be deliberately slowed down).

These aren't the only issues I have with the code. Unicode is abused by "encrypting" text with no discussion of whether the strings he produces are valid or not (as opposed to the normal practice of only encrypting data after first converting it into binary; the encrypted binary might then be converted to text using base64 if you need to transmit the encrypted data as text). We could easily end up with strings containing surrogate high or low code points without the corresponding half in the appropriate place. When analyzing a bitmap he uses GetPixel and SetPixel for each pixel, rather than calling LockBits once and then accessing the image data in a much faster manner. (The code given does scale, but it's not as fast as it could be. Using LockBits it would still scale, but the "per thread" work would be faster.) There are other, similar issues lurking in the text, but I'm sure you get the gist of the problem.

Conclusion

Believe it or not, there are things about this book that I actually like. It's relatively thin, which has very tangible advantages when you're carrying it around a lot. The sections explaining has to use Process Explorer and Task Manager to their best are useful, and the ideas of the examples are good - even though they basically cover the same ground several times. Unfortunately the bad points outweight the good far too heavily. To summarise them:

What I consider some of the absolute core elements of .NET multithreading (locking and monitors in particular) aren't covered at all
Only the simple situation of an embarrassingly parallel algorithm is covered. In the real world developers will have to face real challenges where tasks don't always split themselves up nicely into totally independent chunks. A reader who finishes this book assured that they are now threading gurus will face a nasty shock.
Server-side threading isn't given much coverage at all, despite this being arguably the most likely environment for developers to encounter multithreading
The "story" element of the prose style is childish and patronising
The coding style, while a personal choice, makes me wince - and is particularly verbose for a book, where space is important
Many bad practices are encouraged, and there are plenty of important misunderstandings to trip up readers
The index has failed me (even when I've known that the subject is in the book) more times than it's helped me

It's a real pity. I was hoping this would be a book I could recommend to people as a precursor to reading Joe Duffy's excellent Concurrent Programming on Windows. Instead, my current best advice is to read Joe Albahari's threading tutorial. (I previously had a link to my own threading tutorial as well, but apparently this made people think I was fishing for more readers of that.) I'm sure there are good introductory threading books out there, but I'm afraid this isn't one of them.

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: Pro LINQ - Language Integrated Query in C# 2008, by Joe Rattz

skeet — Mon, 22 Sep 2008 00:57:00 GMT

I'm trying something slightly different this time. Joe (the author) has reacted to specific points of my review, and I think it makes sense to show those reactions. I'd originally hoped to present them so that you could toggle them on or off, but this blog server apparently wants to strip out scripts etc, so the comments are now permanently visible.

Resources

Buy from Amazon or Barnes and Noble
Author's web site
Apress page (errata submissions etc)

Introduction and disclaimer

As usual, I first need to give the disclaimer that as the author of a somewhat-competing book, I may be biased and certainly will have different criteria to most people. In this case the competition aspect is less direct than normal - this book is "LINQ with the C# 3 bits as necessary" whereas my book is "C# 2 and 3 with LINQ API where necessary". However, it's still perfectly possible that a potential reader may try to choose between the two books and buy just one. If you're in that camp, I suggest you buy my book try to find an impartial opinion instead of trusting my review.

A second disclaimer is needed this time: I didn't buy my copy of this book; it was sent to me by Apress at the request of Joe Rattz, specifically for review (and because Joe's a nice guy). I hope readers of my other reviews will be confident that this won't change the honest nature of the review; where there are mistakes or possible improvements, I'm happy to point them out.

Content, audience and overall approach

This book is simply aimed at existing C# developers who want to learn LINQ. There's an assumption that you're already reasonably confident in C# 2 - knowledge of generics is taken as read, for example - but there is brief coverage of using iterator blocks to return sequences. No prior experience of LINQ is required, but the LINQ to XML and LINQ to SQL sections assume (not unreasonably) that you already know XML and SQL.

The book is divided into five parts:

Introduction and C# 3.0 features (50 pages)
LINQ to Objects (130 pages)
LINQ to XML (152 pages)
LINQ to DataSet (42 pages)
LINQ to SQL (204 pages)

The approach to the subject matter changes somewhat through the book. Sometimes it's a concept-by-concept "tutorial style" approach, but for most of the book (particularly the LINQ to Objects and LINQ to XML parts) it reads more like an API reference. Joe recommends that readers tackle the book from cover to cover, but that falls down a bit in the more reference-oriented sections.

[Joe] Early in the development of my book, a friend asked me if it was going to be a tutorial-style book or a reference book. I initially found the question odd because I never really viewed books as being exclusively one or the other. Perhaps I am different than most readers, but when I buy a programming book, I usually read a bit, start coding, and then refer to the book as a reference when needed. This is how I envision my book being used by readers and the type of book I would like for it to be. I see it as both a tutorial and a reference. I want it to be a book that gets used repeatedly, not read once and shelved. Some books work better for this than others. I rarely read a programming book cover to cover because I just don't have time for that. I think ultimately, most authors write the book they would want to read, and that is what I did. I hope that if someone buys my book, in two years it will be tattered and worn from use as a reference, as well as read cover to cover.

I would disagree that the majority of the book reads like an API reference. Certainly, chapters 4 and 5 (deferred and nondeferred operators) work better as a reference because there isn't a lot of connective context between the approximately 50 different standard query operators. At best it would be an eclectic tutorial with little continuity. So I decided to make those two chapters (the ones covering the standard query operators) function more like a reference. I knew that I (and hopefully my readers) would refer to it time and time again for information about the operators, and based on most of the reviews I have seen, this appears to have been a good choice. I know I refer to it myself quite frequently. I would not consider the chapters on LINQ to XML to be reference oriented although I could see why someone might feel they are. My discussion of LINQ to XML is tutorial based as I approach the different tasks a developer would need to accomplish when working with XML, such as how to construct XML, how to output XML, how to input XML, how to traverse XML, etc. However, within a task, like traversing XML, I do list the API calls and discuss them, so this is probably why it feels reference-like to some readers, and will function pretty well as a reference.

For example, take the ordering operators in LINQ - OrderBy, ThenBy, OrderByDescending and ThenByDescending. (Interestingly, one of the Amazon reviews picks up on the same example. I already had it in mind before reading that review.) These four LINQ to Objects operators take 15 pages to cover because every method overload is used, but a lot of it is effectively repeated between different examples. I think more depth could have been achieved in a shorter space by talking about the group as a whole - we only really need to see what happens when a custom comparison is used once, not four times - whereas every example of ThenBy/ThenByDescending used an identity projection, instead of showing how you can make the secondary ordering use some completely different projection (without necessarily using a custom comparer). Likewise I don't remember seeing anything about tertiary orderings, or what the descending orderings tend to do with nulls, or emphasis on the fact that descending orderings aren't just reversed ascending orderings (due to the stability of the sort - the stability was mentioned, but not this important corollary). Having an example for each overload is useful for a reference work, but not for a "read through from start to finish" book.

The set operators (Distinct, Except, Intersect, Union and SequenceEqual) as applied to DataSets suffer a similar problem - the five descriptions of why custom comparers are needed are all basically the same, and could be dealt with once. In particular, one paragraph is repeated verbatim for each operator. Again, that's fine for a reference - but cutting and pasting like this makes for an irritating read when you see the exact same text several times in one reading session.

[Joe] A few readers have complained about some of the redundancies that you have pointed out, but I think most of the readers have appreciated my attempt to provide material for each operator/method. I think one of the words you will see most often in the Amazon reviews is "thorough".

Now, it's important that I don't give the wrong impression here. This is certainly not just a reference book, and there's enough introduction to topics to help readers along. If I'd been coming to C# 3 and LINQ without any other information, I think I'd have followed things, for the most part. (I'm not a fan of the way Joe presented the query expression translations, but I'm enormously pleased that he did it at all. I think I might have got lost at that point, which was unfortunately early in the book. It might have been better as just an appendix.) Anyone reading the book thoroughly should come away with a competent knowledge of LINQ and the ability to use it profitably. They may well be less comfortable with the new features of C# 3, as they're only covered briefly - but that's entirely appropriate given the title and target of the book. (To be blunt and selfish, I'm entirely in favour of books which leave room for more depth at a language level - that should be a good thing for sales of my own book!)

[Joe] Jon, if you only knew how difficult it was getting those query expression translations into the book. ;-) You can read in my acknowledgments where I specifically thank Katie Stence and her team for them. They were a very painful effort and in hindsight, I probably would not include them if I were to start the book from scratch. I agree with you that the translations are complex, as the book states. Perhaps the most important part of that section is when I state "Allow me to provide a word of warning. The soon to be described translation steps are quite complicated. Do not allow this to discourage you. You no more need to fully understand the translation steps to write LINQ queries than you need to know how the compiler translates the foreach statement to use it. They are here to provide additional translation information should you need it, which should be rarely, or never."

However, I would personally have preferred to see a more conceptual approach which spent more time focused on getting the ideas through at a deep level and less time making sure that every overload was covered. After all, MSDN does a reasonable job as a reference - and the book's web site could have contained an example for every overload if necessary without everything making it into print. The kind of thing I'd have liked to see explored more fully is the buffering vs streaming nature of data flow in LINQ. Some operators - Select and Where, for example - stream all their data through. They never keep look at more than one item of data at a time. Others (Reverse and OrderBy, for example) have to buffer up all the data in the sequence before yielding any of it. Still others use two sequences, and may buffer one sequence and stream the other - Join and Intersect work that way at the moment, although as we saw in my last blog post Intersect can be implemented in a way which streams both sequences (but still needs to keep a buffer of data it's already seen). When you're working with an infinite (or perhaps just very large - much bigger than memory) sequence you really need to be aware of this distinction, but it isn't covered in Pro LINQ as far as I remember. In the interests of balance, I should point out that the difference between immediate and deferred execution is explained, repeatedly and clearly - including the semi-immediate execution which can occur sometimes in LINQ to SQL.

[Joe] I wanted my book to cover each overload because I can't read MSDN in the bathroom, or when at the beach without an internet connection, or when curled up in a chair by the fireplace. I also wanted to provide examples for every method and overload because I find it frustrating when a book shows the simplest one and I have to figure out the one I need. Granted, depth could be added too, but you have to draw the line somewhere. Apress (at the time, not sure if this is still the plan) has the concept of three levels of book; Foundations, Pro, and Expert. I considered some information beyond the scope of the Pro level that my book is aimed at. The buffering versus streaming issue is an interesting one and would make an excellent additional column in Table 3-1, if I can get it to fit.

I'm unable to really judge the depth to which LINQ to SQL was explored, given that a lot of it was beyond my own initial knowledge (which is a good thing!). I'm slightly perturbed by the idea that it can be comprehensively tackled in a couple of hundred pages, whereas books on other ORMs are often much bigger and tackle topics such as session lifetimes and caching in much more depth. I suspect this is more due to the technologies than the writing here - LINQ to SQL is a relatively feature-poor ORM compared with, say, Hibernate - but a bit more attention to "here are options to consider when writing an application" would have been welcome.

Accuracy and code style

Most of Pro LINQ is pretty accurate. Joe is occasionally a bit off in terms of terminology, but that probably bothers most readers less than it bothers me. There are a few things which changed between the beta version of VS2008 against which the book was clearly developed and the release version, which affect the new features of C# 3. For instance, automatically implemented properties aren't mentioned at all (and would have been much nicer to see in examples than public fields) and collection initializers are described with the old restrictions (the collection type has to implement ICollection<T>) rather than the new ones (the collection type has to implement IEnumerable and have appropriate Add methods). Other errors include trusting the documentation too much (witness the behaviour of Intersect) and an inconsistency (stating correctly that OrderBy is stable on one page, then incorrectly warning that it's unstable on another). In my normal fashion, I'll give Joe an exhaustive list of everything I've found and leave it up to him to see which he'd like to fix for the next printing, but overall Pro LINQ does pretty well. I suspect this may be partly due to covering a great deal of area but with relatively little depth and some repetition - Accelerated C# had a higher error rate, but was delving into more treacherous waters, for example.

[Joe] Since my book is not meant to be a C# 3.0 book, but rather a LINQ book, I only cover the new C# 3.0 features which were added to support LINQ. Since automatic properties were not one of those features, I do not cover them. You may notice that my chapter dedicated to the new C# 3.0 features is titled C# 3.0 Language Enhancements For LINQ. Just for your reader's knowledge, the ordering is now specified to be stable. Initially it was unstable, and was later changed to be stable but I was told it would be specified to be unstable, but apparently at some point, the specification was changed to be stable. My book was updated but apparently I missed a spot.

Most of the advice given throughout the book is reasonable, although I take issue with one significant area. Joe recommends using the OfType operator instead of the Cast operator, because when a nongeneric collection contains the "wrong type of object," OfType will silently skip it whereas Cast will throw an exception. I recommend using Cast for exactly the same reason! If I've got an object of an unexpected type in my collection, I want to know about it as soon as possible. Throwing an exception tells me what's going on immediately, instead of hiding the problem. It's usually the better behaviour, unless you explicitly have reason to believe that you will legitimately have objects of different types in the collection and you really want to only find objects of the specified type.

[Joe] Yes, I should have known better than to provide that advice (prefer OfType to Cast) without more explanation, more disclaimers, and more caveats. My preference would be to use Cast in development and debug built code for the exact reasons you mention, but to use OfType in production code. I would prefer my applications to handle unexpected data more gracefully in production than I would in development.

As well as "headline" pieces of advice which are advertised right up to the table of contents, there are many hints and tips along the way, most of which really do add value. I believe they'd actually add more value if they weren't sometimes buried within reference-like material - but as we've already seen, my personal preference is for a more narrative style of book anyway.

The code examples are in "snippet" form (i.e. without using directives, Main method declarations etc) but are complete aside from that. At the start of each chapter there's a detailed list of which namespaces and references are involved, so there's no guesswork required. In fact, I'd expect most of them to work in Snippy given an appropriate environment. Some examples are a bit longwinded - we only really need to see the 7 lines showing the list of presidents once or twice, not over and over again - but that's a minor issue. Another niggle is Joe's choices when it comes to a few bits of coding convention. There are various areas where we differ, but a few repeatedly bothered me: overuse (to my mind) of parentheses, "old-style" delegate creation (i.e. something.Click += new EventHandler(Foo) instead of just something.Click += Foo) and the explicit specification of type parameters on LINQ operators which don't need them. Here's one example which demonstrates the first and the last of these issues - as well as introducing an unnecessary cast:

// This is the code in the book (in listing 7-30)
XElement outOfPrintParticipant = xDocument
.Element("BookParticipants")
.Elements("BookParticipant")
.Where(e => ((string)((XElement)e).Element("FirstName")) == "Joe"
&& ((string)((XElement)e).Element("LastName")) == "Rattz")
.Single<XElement>();

// This is what I'd have preferred
XElement outOfPrintParticipant = xDocument
.Element("BookParticipants")
.Elements("BookParticipant")
.Where(e => (string)e.Element("FirstName") == "Joe"
&& (string)e.Element("LastName") == "Rattz")
.Single();

Check out the penultimate line of the original - a whopping 5 opening brackets and 6 closing ones. This issue looks even worse to me when it's used to make return and throw look like method calls:

// From GetStringFromDb (P388)
throw (new Exception(
String.Format("Unexpected exception executing query [{0}].", sqlQuery)));

// (Insert more code here) - same listing

return (result);

These just look odd and wrong. Of course they're perfectly valid, but not pleasant to read in my view. On a more minor matter, Joe tends to close SQL connections, commands etc with an explicit try/finally block instead of the more idiomatic (to my mind) using statement, but again that probably bothers me more than others.

The source code is all available on the web site, and it's easy to find each listing. (The zip file is about 10 times larger than it needs to be because it contains all the bin/obj directories with all the compiled code in rather than just the source, but that's a tiny niggle.)

Writing style

Joe's writing style is very informal - or at least, while most of the text is in "normal" formal prose, there are plenty of informal pieces of writing there too. As readers of my book will know, I'm much the same - I try to keep things from getting too dry, despite that being the natural state for technical teaching. I have no idea how well I succeed for most readers, but Joe certainly manages. He occasionally takes it a little too far for my personal taste, usually around listing outputs. They're often introduced as if Joe didn't really know what the output would be, with a kind of "wow, it worked, who'd have thought?" comment afterwards. I suspect I've got some of this in my book too, but Joe lays it on a little too thickly for my liking. I don't know whether it would be fairer to present a "medium-level" example of this rather than one which really grated, but this is the one (from page 257) made such an impression that I remembered it over 300 pages later:

This should output the language attribute. Let's see:
language="English"
Groovy! I have never actually written the word groovy before. I had to let the spelling checker spell it for me.

Now, I really want to stress that that's a "worst case" rather than the average case, and indeed many listings don't have anything "cutesy" about them. I just wanted to give an example of the kind of thing that didn't work for me.

[Joe] Let me see if I get this straight. So you are saying you got to learn something about LINQ and how to spell groovy, and it stuck for over 300 pages and you are upset? Man, you know how to spell groovy now, what's the problem? 8-D Would it annoy you less if I told you that is a reference to Austin Powers? My book is riddled with references to movies and TV shows, and that one is for Austin Powers. Maybe you didn't catch that, or maybe you don't like Austin Powers, or maybe you just still don't like it. One reader was irritated when I said "Dude, Sweet" because he didn't recognize that as a reference to Dude, Where's My Car. I have references to Office Space, Arrested Development, Bottle Rocket, Seinfeld, The Matrix, Wargames, Tron, etc. In fact, on page 455, I actually use the word "moo" instead of "moot" in reference to Friends. My copy editor actually corrected that for me, but once I explained it, she let me have it back. So if you see something goofy, like "groovy" just know it is a reference to something and begin your investigation in your spare time. And if you see an error, it is intentional to make sure you are paying attention. ;-) As you have already pointed out, technical writing can be dry. I made an effort to inject humor into the book in the form of references to pop culture, most specifically movies and television. Sometimes the reference is in a comment like "groovy", and sometimes it's in the sample data like a character's name. Like any comedian, every joke or reference can't be a hit with everyone. I will say though that I have heard more from those that recognized the references and appreciated them (which helps carry a reader through the lesser interesting parts) than I have from those that found them annoying.

What really did work was including hints and tips which explicitly said where Joe had received unexpected results with slightly different code. If anything is unexpected to the author, it may well be unexpected to readers too, so I really appreciated reading that sort of thing. (It would be wearing if Joe were stupid and expected all kinds of silly results, but that's not the case at all.)

Conclusion

Pro LINQ is a good book. It has enough niggles to keep me from using superlatives about it, but it's good nonetheless. It's Joe's first book (just like C# in Depth is the first one I can truly call "mine") and I hope he writes more. Having read it from cover to cover, I think it'll be more useful as a reference for individual methods (when MSDN doesn't quite cut it) than to reread whole chapters, but that's not a problem. My slight complaints above certainly don't stop it from being a book I'm pleased to own.

[Joe] I'll take it as a compliment that you think my book would be useful for those times that MSDN isn't good enough!

This is the first LINQ book I've reviewed - I already have LINQ in Action, which is also on the list to review at some point. (I've read large chunks of it in soft copy, but I haven't been through the finished hard copy yet.) It will be interesting to see how the two compare. Next up will probably be "Programming C# 3.0" by Jesse Liberty, however.

Book reviews - what do you look for?

skeet — Sun, 14 Sep 2008 15:37:30 GMT

I've just started writing the book review for "Pro LINQ - Language Integrated Query in C# 2008" and I wondered what people look for in a review. I've talked before about who is in the best position to write a review - but this is slightly different. In particular, what sort of balance do you want between totally factual aspects (what's covered, the kinds of mistakes I found) and pretty subjective aspects (the writing style, quality of advice given)? Is a long and detailed review useful, or are you likely to just skip to the conclusion anyway?

I guess it's worth answering my own question, partly in the hope that someone will write this kind of review for C# in Depth. (There are plenty of reviews, but not many in significant detail.) Here's what I like to see:

A mixture of subjective opinions and objective facts
An example or two of the kind of technical errors found, and a rough idea of how often such errors occur
Who the book is aimed at, and more subjectively who it wouldn't be useful for
A brief summary of what's covered - and what's not covered, if that's relevant
A feeling of how well structured/ordered the book is - does it lead the reader through the technology, or jump around?
An idea of the author's style - formal or informal, reference or tutorial, etc
Which aspects of that style irked the reader, and which worked well
Exampes of all of this! It's one thing to say that a style annoys you - it's another to give an example which will let the review's reader judge for themselves.
How the author could improve, and their existing strengths
A final gut feeling of how much you like the book, despite/because of the above

Not all of these are suitable for all books, and I wouldn't like to say that my own reviews have included all of them so far, but I think that's what I'd appreciate reading. That suggests a fairly comprehensive review, of course - which is just what I'm after when making a reading decision.

I'd love to know what you think - it won't be in time to affect the review I'm writing now, of course, but I'll try to take comments into account for future reviews.

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.

The trouble with book reviews

skeet — Tue, 08 Jul 2008 17:07:14 GMT

I'm currently reading two .NET books: Accelerated C# 2008 (Trey Nash) and Concurrent Programming on Windows (Joe Duffy). I will, in due course, post reviews here. However, the very act of thinking about the reviews has made me consider the inevitable inadequacies.

There tend to be two kinds of people reviewing technical books: those who've bought the book as a "regular punter" - who are aiming to learn something new. Then there are those who already know about the subject matter, but are reading the book mostly to review it. I realise there are people in-between (for whom the problems below aren't such an issue) but these are the two camps this post addresses.

The purpose of a technical book is usually to impart information and wisdom. I would have left it at just information, but things like best practices don't really count as "facts" as such - they are opinions and should be treated as such. So, there are two qualities that I look for in a book:

Is it accurate? Are the facts correct, and is the wisdom genuinely wise?
Is it a good teaching tool? How well is the information/wisdom transferred from author to reader?

I think it's worth breaking these up, although there is significant overlap.

Accuracy

As I've noted before, I'm a stickler for accuracy. If I can spot a significant number of inaccuracies in the text, I find it hard to trust the rest. Now I generally don't include grammatical errors, printing mistakes etc in this. While they make the book harder to read, they don't typically leave me with a mistaken impression about the technology I'm trying to learn. There's a blurring of the medium and the message when a book may be technically just about accurate, but still leaves an incorrect impression.

Now, the reader who has bought a book primarily to learn something new has little hope of judging accuracy. They can spot typos, and if the book is inconsistent or simply implausible that can become obvious - but subtle errors are likely to elude them. Just because an error is subtle doesn't mean it's unimportant, however. I know a reasonable amount about threading in .NET, but there's a lot of Joe Duffy's book which is new to me. He could have made dozens of mistakes in the text around Win32 threading, and I'd never know until it bit me. (For what it's worth, I very much doubt that there are dozens of mistakes in the book.)

A reader who already knows the subject matter thoroughly is much more likely to spot the mistakes. However, they're unlikely to be much good at judging the other major criterion...

Teaching efficacy

I can't really remember much about how I learned to program, other than that it was over the course of several years. I started off with Basic on the ZX Spectrum, then moved on to C, then Java, then C#. Each experience built on the previous one. The way in which I learned C# wouldn't have suited a non-Java programmer nearly as well as it suited me.

How can I possibly judge how well a book will teach a subject I already know? I can make some educated guesses about particularly confusing passages, and potentially critique the ordering of material (and indeed its inclusion/exclusion) but fundamentally it's impossible to gauge it properly.

The people who don't know the topic beforehand are likely to have a better idea, but it will still be flawed. In particular, you won't know how well the material has sunk in until you've given yourself enough time to forget it. You won't know how suitable the advice (wisdom) was until you've tried to follow it. You won't know how complete the coverage is until you've used the technology in anger, preferably over the course of several projects. Even then it's easy to miss stuff: if no-one on your team knew about iterator blocks and the C# book you were reading didn't mention them, how would you know what you were missing?

Who should you trust?

This post has had a pretty depressing mood so far. That reflects my irritation with the whole topic - which isn't to say I don't enjoy reviewing books. I just have doubts as to their use. I do, however, have a few positive notes to end on, as well as some fairly self-evident advice:

If everyone likes a book, it's probably good. Likewise unanimous disapproval is rarely a good sign.
When judging reviews, see if you can work out the context. Is the reviewer reading from a perspective of knowledge, or learning? If they're criticising accuracy, they probably know what they're talking about - but may not be a good judge of the style and teaching technique. If the review is mostly saying, "I learned C# from scratch in 20 minutes with the help of this fabulous book!" then you can guess that they at least believe they had a positive learning experience, but you should treat anything they say about accuracy and completeness with care.
Blogs tend to have more "expert" reviewers than ecommerce sites - although often bloggers will be encouraged to post reviews to Amazon as well.
Look for reviews which give specific praise/criticism. In particular if they give examples of teaching techniques, you will have more of an idea as to whether it'll suit you. Reviews which basically say "I loved it!" or "That's rubbish!" aren't terribly informative.

On that note, I should probably stop. That's another train journey gone that I should probably have spent actually reading... ah well. Please comment if you have other suggestions with regards to reviewing - particularly if it could help me to review books in a more useful way in the future.

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: User Interface Design for Programmers (Joel Spolsky)

skeet — Sat, 19 Apr 2008 16:21:00 GMT

Resources

Joel on Software (Joel's blog)
Amazon

Introduction

This will be a brief review. It's a short book, after all - a mere 134 pages for the main body of the book. That's not a bad thing at all, mind - quite the opposite. This book is a quick read, and it's easy to read the whole thing without skimming over anything.

I'm not good at UI design, either on the web or for rich client apps. My applications tend to be functional but not pretty - and even in "functional" terms I strongly suspect users don't always find my choices intuitive. Fortunately, so far in my professional career I haven't actually had to work on many front ends - but should that time come, this book will prove a good starting point for me.

The Good

If you want to know all the latest and greatest technical tricks for user interfaces, this isn't the book for you. If you've taken a course in usability or HCI, this probably isn't the book for you. It really is just introductory material - but it certainly seems to be a good way of starting to think in the right way when designing user interfaces. It tries to educate in terms of an approach to take rather than the details of what to do.

There are 18 bitesize chapters, almost all of which contain many illustrations and screenshots. The production quality of the book is fabulous - it's full colour on glossy paper, and the screenshots are all large enough to easily illustrate the point being made. It must have cost APress a fortune to print, but the results are well worth it, in my view. It's not often that production is of such a high quality as to really make an impression (for me, anyway) but it really does grab attention. Oh, and I only spotted a single typo in the single book. I didn't find technical errors at all, but then the material isn't really directly technical to start with - and I'm not an expert on the topic.

The tone is conversational throughout, which may not be to everyone's taste but is absolutely fine by me. It's lighthearted without ever being patronising, and it's clear that Joel is deadly serious about the subject matter itself. There are lots of examples of what works and what doesn't - but always with clear, purposeful commentary rather than just as a UI hall of shame.

Joel describes how best to consider users, and how they're likely to think. He focuses on the limitations of the user, in terms of how they're unlikely to read documentation or even on-screen instructions; how requiring users to aim a mouse accurately is basically cruel; how the user's model of your program probably isn't the same as yours - and more. None of this is actually belittling towards the user - it's just a case of different perspectives. He makes it crystal clear that the user has launched an application to accomplish a task, rather than for the joy of the application itself - so it's understandable that if the user can't accomplish their task simply (without excessive training), it's generally the application's fault rather than the user's.

Although that summarises the basic message of the book, it doesn't do justice to the close attention paid to exactly how those ideas manifest themselves in real world situations. I'm afraid it's one of those books where just talking about which areas are covered doesn't really give much of a feeling of the book itself. However, the writing is very similar to Joel's blog posts - so if you enjoy those, I'd say you're likely to enjoy the book. (I don't agree with all of what Joel says on his blog, I should say - but whether or not I agree with his point, his writing style generally appeals to me.)

The Bad

Okay, it's not perfect - but my main gripe isn't really the book's fault. It was written in 2001, and has certainly dated when it comes to web access. I would love to see a second edition written right now, touching on the pros and cons (from a user perspective instead of a technical one) of more modern web applications. One topic which should have had more attention paid to it even back in 2001 is accessibility

Finally, I do wish Joel would be slightly kinder towards the programmers behind the interfaces he disparages. This may seem a little odd coming from someone who has made a point of being brutally honest when it comes to low opinions of books, products, articles etc - but occasionally this book goes too far, in my view. Negativity can form constructive criticism, and when it's directed at the user interfaces themselves, everything's fine - but when it's aimed at the developers it just doesn't feel right.

Conclusion

If you're in the target market for the book, it really is excellent. Just don't get it expecting technical tricks or detailed discussion about each individual control.

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

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)

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.)