Book Review: Fluent C# (Rebecca Riordan, Sams)

(As usual, I will be sending the publisher a copy of this review to give them and the author a chance to reply to it before I publish it to the blog. Other than including their comments and correcting any factual mistakes they may point out, I don’t intend to change the review itself.)

Resources:

Introduction and disclaimers

In late October, Sams (the publisher) approached me to ask if I’d be interested in reviewing their newest introductory book on C#. Despite my burgeoning review stack, I said I was interested – I’m always on the lookout for good books to recommend. So, the first disclaimer is that this was a review copy – I didn’t have to pay for it. I don’t believe that has biased this review though.

Second disclaimer: obviously as C# in Depth is also "a book about C#" you might be wondering whether the two books are competitors. I don’t believe this is the case: Fluent C# explicitly talks about its target audience, which is primarily complete newcomers to programming. C# in Depth pretty much requires you to know at least C# 1, or perhaps be very comfortable with a similar language such as Java. I find it hard to imagine someone for whom both books would be suitable.

Obviously that puts me firmly out of the target audience. As I’ve written before, if you think the two most important questions to answer in a technical book review are "Is it accurate?" and "How good is at teaching its topic?" then any one person will find it hard to answer both questions. Although I’m far from an expert in some of the areas of the book – notably WPF – I’m sure I don’t have the same approach as a true newcomer. In particular, I find myself asking the questions I’d need the answers to in order to develop software professionally: how do I test it? How does the deployment model work? How does the data flow? These aren’t the same concerns as someone who is coming to programming for the first time. This review should be read with that context in mind: that my approach to the subject matter won’t be the same as a regular reader’s.

Physical format and style

Fluent C# is very reminiscent of Head-First C# in its approach, even down to the introductory "why this book is great at teaching you" blurb. It’s all very informal, with lots of pictures, diagrams and reader exercises. It’s a chunky book, at nearly 900 pages including the index – which I’d expect to be pretty daunting to a newcomer. However, that isn’t the main impression you come away with. Instead…

It’s brown. Everywhere. The diagrams, the text, the pictures – they’re all printed in brown, on off-white paper.

Combined with using multiple fonts including cursive ones, this makes for a pointlessly irritating reading experience right from the outset, however good or bad the actual content is. Now it’s possible that this is actually deliberate: I was speaking to someone recently who mentioned some research that shows if you use a hard-to-read font in presentations, people tend to end up reading it several times, so you end up with better memories of the content than if it had been "clean". I don’t know if that’s what Sams intended with this book, but I frequently found myself longing for simple black ink on clean white paper.

Leaving that to one side, I’m not sure I’ll ever really be a fan of the general tone of books like this, but I can certainly see that it’s popular and therefore presumably helpful to many people. It’s not clear to me whether it’s possible to create a book which retains the valuable elements of this style while casting off the aspects which rub me up the wrong way. It’s something about the enforced jollity which just doesn’t quite sit right, but it wouldn’t surprise me if that were more a peculiarity of my personality than anything about the book. Again, I’ve tried to set this to one side when reviewing the book, but it may come through nonetheless.

Structure

The book is broken up into the following sections, with several chapters per section:

  • Getting started (122 pages – finding your way around Visual Studio, debugging, deployment)
  • The Language (100 pages – introduction to C#)
  • The .NET Framework Library (162 pages – text, date/time APIs, collections – and actually more about C# as a language)
  • Best practice (116 pages – inheritance, some principles, design patterns)
  • WPF (341 pages)

I’ve included the page count for each section to show just how much is devoted to WPF. The book goes into much more detail about WPF than it does about the C# language itself (for example, drop shadow effects are included, but the "using" statement and nullable value types aren’t). If you want to write any kind of application other than a WPF one, a large part of the book won’t be useful to you. That’s not to say it’s useless per se – and in fact from my point of view, the WPF section was the most useful. The section on brushes is probably the best written in the whole book, for example. At time it feels to me like the author really wanted to write a book about WPF, but was asked to make it one about C# instead. That may well not be the case at all – it was just an impression.

Even though the best practice section talks briefly about MVC, MVP and MVVM, it doesn’t really go into enough detail to build anything like a real application – and in fact there’s no coverage of persistence of any form. No files, no XML, no database – nothing below the presentation layer, really. As such, although the book claims it’s enough to get you started with application development, it actually only provides a veneer. Even though I didn’t like the first edition of Head-First C# back in 2008, it did at least take the reader end-to-end – the exercises led to complete applications. The best practice section isn’t entirely about architecture and design patterns, however – it’s at this point that inheritance is properly introduced. While I wouldn’t personally count that as a "best practice" as such, it does at least come at the start of the section, before the genuine patterns/architecture areas which would have been harder to understand without that background.

One aspect which concerned me was the emphasis on the debugger and interactive diagnostics. The author states that developers should expect to spend a large part of their time in the debugger, and she says how she prefers using MessageBox.Show for diagnostics over Console.WriteLine information appearing in the output window. While I’m all for something more sophisticated than Console.WriteLine, there are solutions which are a lot less invasive than popping up a dialog, and which can be left in the code (possibly under an execution-time configuration) to allow diagnostics to be produced for real systems.

The "testing and deployment" chapter says nothing about automated tests – it’s as if the author believes that "testing" only involves "running the app in the debugger and seeing if it breaks". I hope that’s not actually the case, and I can understand why newcomers ought to at least know about the debugger – but I’d have welcomed at least a few pages introducing unit testing as a way of recording and checking expectations of how your code behaves. My own preference is to spend as little time in the debugger as possible; I know that’s not always practical, particularly for UI work, but I think it’s a reasonable aim.

Accuracy

Anyone following me on Twitter or Google+ knows where I’m going with this section. After reading through the book, pen in hand (as I always do, even for the books I like), I decided that it was more important to get out some form of errata quickly than this review. As such, I started a Google document which is publicly available to read and add comments to. The result is over 60 pages of notes and errata, and that’s excluding the introduction and table of contents. To be fair to the book, some of those notes are matters of disagreement which are more personal opinion than incontrovertible fact – but there are plenty of simple matters of inaccuracy. Some of the worst are:

  • Claims that String is a value type. (It’s a reference type.)
  • Inconsistency between whether arrays are value types or reference types – but consistently claiming that arrays are immutable, with the exception of the size which can be changed (slowly) using Array.Resize. (Array types are always reference types, and they’re always mutable except the size, which is fixed after creation. Array.Resize creates a new array, it doesn’t change the size of the existing one.)
  • Incorrect syntax for chaining from one constructor to another.
  • The claim that all reference types are mutable. (Some aren’t, and indeed I often aim for immutability. The canonical example of an immutable reference type is String.)

There are plenty more – including huge number of samples which simply won’t compile. Whole double page spreads where every class declaration is missing the "class" keyword. Pieces of code using VB syntax… the list goes on. (The VB syntax errors are probably explained by the author’s other book published at the same time: "Fluent Visual Basic". I suspect there was a certain amount of copy/paste, and the editing process didn’t catch all the changes which were needed to reflect the differences between the languages.)

Beyond the factually incorrect statements, there’s the matter of terminology. Now I’m well aware that I care more about terminology than more people – but there’s simply no reason to start making up terminology or misusing the perfectly good terminology from the specification. The book has a whole section on "commands" in C#, including things like for statements, switch statements, try/catch/finally statements. Additionally, it mislabels class and namespace declarations as "statements", and even mislabels using directives as statements – although it later goes back on the latter point. The word "object" is used at various times to mean any of variable, type, class and object, with no sense of consistency that I could fathom. For example, at one point it’s used in two different senses within the same sentence: "As we’ll see, you can define several different kinds of objects (called TYPES) in C#, but the one you’ll probably work with most often is the OBJECT."

Both accuracy and staying consistent with accepted terminology (primarily the specification) are particularly important for newcomers. If there’s a typo in a relatively advanced book – or in one which is about a particular technology (e.g. MVC) rather than an introductory text on a language, the reader is fairly likely to be able to guess what should really be there based on their existing experience. If a beginner comes across the same problem, they’re likely to assume it’s their fault that the code won’t compile. Likewise if they learn the wrong terminology to start with, they’ll be severely hampered in communicating effectively with other developers – as well as when reading other books.

I don’t want to make it sound like I expect perfection in a book – just yesterday someone mailed me a correction to C# in Depth, and I’d be foolish to try to hold other authors to standards I couldn’t meet myself. Nor am I suggesting it’s easy to be both accessible and accurate – so often an author may have an accurate picture of a complex topic, but have to simplify it in their writing, particularly for an introductory book like Fluent C#. But there are limits – and in my view this book goes well past the level of error that I’m willing to put up with.

Conclusion

I really don’t like ranting. I don’t like sounding mean – and I wanted to like this book. While I like C# 4.0 in a Nutshell and Essential C# 4.0, I’m still looking for a book which I can recommend to readers who want a more "lively" kind of book. Unfortunately I really can’t recommend Fluent C# to anyone – it is simply too inaccurate, and I believe it will cause confusion and instil bad habits in its readers.

So, what next? I’m hoping that the publisher and author will take my errata on board for the next printing, and revise it thoroughly. At that point I still don’t think I’d actually like the book due to its structure and WPF focus (and the colour scheme, which I don’t expect to change), but it would at least be more a matter of taste then.

I have some reason to be hopeful – because my review of Head-First C# was somewhat like this one, and one of the authors of that book (Andrew Stellman) was incredibly good about the whole thing, and as a result the second edition of Head-First C# is a much better book than the first edition. Again, it’s not quite my preferred style, but for readers who like that sort of thing, it’s a much better option than Fluent C# at the moment, and one I’m happy to recommend (with the express caveat of getting the second edition).

At the same time, reading Fluent C# (and particularly thinking about its debugger-first approach) has set me something of a challenge. You see, I’ve mostly avoided writing for new programmers so far – but I feel it’s really important to get folks off on the right foot, and I’d like to have a stab at it. In particular, I would like to see if it’s possible to write an introductory text which teaches C# using unit tests wherever possible… but without being dry. Can we have a "fun" but accurate book, which tries to teach C# from scratch without giving the impression that user interfaces are the be-all and end-all of programming? Can I write in a way which is more personal but doesn’t feel artificial? I can’t see myself starting such a project any time in the next year, but maybe some time in 2013… Watch this space. In the meantime, I’ll keep an eye out for any more introductory books which might be more promising than Fluent C#.

30 thoughts on “Book Review: Fluent C# (Rebecca Riordan, Sams)”

  1. I’ve been following your tweets on this review for a while now and must say its nice seeing someone thats completely honest (not always popular) about something.

    I hope the author(s) of this book value criticism (to the point of action), you’re actually an incredible valuable “ally” to them – hope they see it like that, people tend to be a bit sensitive.

    Looking at myself, I know if I ever get the chance to write a book I am sure it will be complete rubbish – mainly because of my programming background.

    I’ve been programming for over 20 years (started at a very young age) and didnt have any mentors (everyone needs a mentor I feel) and didnt have a lot of interaction with the programming community in that time, only recently got the opportunity to work alongside other programmers (my use of terminology might give you a heart attack).

    I am luckily always open to learn and change, not set in my ways, I believe we must always be open to learn anything from anyone (pride and ego cant have place in the process of learning)

  2. To start out the best book to read is C# in nutshell. Highly recommended because its more that a technical reference. It actually reads like a novel :) Once you are more experienced then the book of Mr Skeet is a very good read. I would love to see your beginner text and read it if I got started.

    (Off topic, the comment captche doesn’t seem to work in Chrome)

  3. @Christoff, you’re reading a programming blog, which I fear already makes you part of the programming elite…

    @Jon, it would be interesting to see if by writing a ‘beginners’ book, you could reach the parts that blogs don’t.

  4. Every book I’ve written started with me assuming it already existed, trying to find it, and failing.

    If you find yourself thinking seriously about going the beginner book route, and you decide you want to work with a publisher who’s strong in that niche, drop me a line—I’d be happy to introduce you.

  5. Was the book already publicly available in October when you began your review? If so, did you consider opening a direct channel of communication with Sams as an alternative?

  6. @Chris: I began reviewing in mid to late November. I already had a direct channel of communication with Sams, as that’s how I got the review copy. I submitted the review to them two weeks ago, and let them know of the errata document at the same time as publishing it for everyone. (I saw no reason to wait for that one, but wanted to give them a chance to add comments/notes/corrections for the review itself.)

  7. Good review Jon,

    Not sure this book can ever become more than adequate despite your best efforts. :)

    More interestingly is the prospect of you or someone else delivering a really good, accessible C# book that uses TDD and introduces Design Patterns to new C# programmers with real-world programming scenarios. I think there is a real need for this kind of book.

    Having recently tried to recruit C# programmers for the company I work for I have noticed there is a distinct lack of TDD knowledge amongst the candidates. Some can give you an explanation for what TDD is but they don’t seem convinced by it and very few have actually done any proper, test first, development. Also very few know LINQ to any real degree (!) or can explain why SRP or any other of the SOLID principles are good things to bear in mind whilst programming. And these are C# developers with sometimes 5 years or more experience.

    I partially blame Microsoft for not shipping MSTest with their Express versions. Sure you can use NUnit but most new devs won’t. If it was there in the entry level C# IDE perhaps more people would see unit testing as the natural way to develop code.

  8. The thing with the brown text/imagery on beige paper, could that be some kind of effort to prevent it being scanned and distributed before release?

    Sounds like the anti-piracy stuff from the 80′s where you’d get a code sheet printed on green paper so it could not be duplicated.

    Pointless and annoying, maybe it is to push eBook versions.

  9. @Ryan: I don’t think it’s an anti-piracy measure. (Don’t forget I received my copy *after* release – this wasn’t a preview copy or anything like that.) It fits in with the fonts used in the book – but it’s simply annoying to read.

    It could certainly be a push for eBook versions, but that would seem like an odd approach to me.

  10. @Karl: I wouldn’t claim to do “full” TDD, and I would try not to be particularly dogmatic about it in the book – I’d talk about TDD, but the tests wouldn’t really be driving the design so much as a useful way of keeping both the results and the code in the same place, rather than saying “The output of this code is x…”

    But yes, I wish MS had shipped testing in Express editions too. Indeed, I pushed Soma on that point back in 2005 :) It’s making its way down gradually, but it’s not there yet…

  11. @Omer: I was surprised when I read that too, but then it’s also entirely possible that she’s changed her opinions since then.

  12. Why on earth is someone who things strings in .Net are value types and that arrays can be resized writing a book. It beggars belief.

  13. @Omer Mor: Oh and this is a gem. really?

    “Rebecca: Not with an entire language—I was never that ambitious—but I do remember one particularly cringe-making moment when someone pointed out that if I was calculating an 80-character line break, it was probably more efficient to start at character 79 and scan backward for a space than to start at character 0 and scan forward and then backward. It was then that I decided I really wasn’t cut out to be a programmer and moved into systems analysis.”

  14. @ShuggyCoUk: It’s probably best to focus on the book, not the author. I have nothing personal against Rebecca Riordan, and wish her well in general – I just don’t like this particular book.

  15. From Amazon: “This book didn’t just teach me C#, I also feel like I’m starting to know my way arond the .NET Framework and WPF also.”

    Great, yet another worthless .NET “developer” out there now. Just what we need.

  16. @Jon

    Fair enough, Her SQL books seem well respected. I’m surprised she segued into programming directly given her previous statements is all.

  17. You ask: Can we have a “fun” but accurate book, which tries to teach C# from scratch…?

    I am loving C# in Depth (reading it now), and I heartily encourage you to consider writing a book for beginners. For a book to be fun, it doesn’t need to be whimsical or frenetic; it needs to be clear and empowering. Reading something that makes a new concept _click_ and then working through a practical example at which I succeed–that’s fun! Unlike history or biology or painting, programming gives you objective confirmation that you’re progressing. You can see yourself succeeding, and you have an environment in which to experiment. With a patient, empathetic mentor (that’s where you come in, as book author), programming is inherently fun.

    I don’t currently have a book to recommend to friends who want to learn C#, just a bunch I warn them away from. Please consider writing a beginner book. You would be excellent at it.

  18. I agree with @Sharon Cichelli. I have some nephews who have expressed a strong interest in programming. I’d love to give them books for Christmas but so much of the introductory stuff is so terrible that I can’t bear to give it to them.

    (Captcha is still broken in Chrome)

  19. I started .NET programming as a VB.NET programmer and avoided C# until 2.0 when I wanted use generics. I then realized C# was more eloquant in syntax. I haven’t used VB.NET since.

    I had a coworker back in 2004 hate .NET with a passion because he hated VB.NET (our company used it at the time). From a Java background, when he ‘discovered’ C# he was a convert.

    In any case, my point being whatever people say in the past, is always subject to change. Perhaps something happened to the author that made her enjoy C# so strongly that she felt compelled to write the book to try to help others overcome some obstacle she herself perceived.

  20. I found Illustrated C# to be a good beginner’s guide when I was looking around a few years ago. I felt it had the clearest explanations of the books I saw.

    Thanks for the (as always) in-depth review.

    (captcha is still broken in Chrome)

  21. Finding good programming books is really hard, I suppose because the skills required for writing books and writing code don’t really overlap too much.
    I read the Head First book on design patterns and while the information there was useful, the forced ‘humour’ made me want to throw the book out of the window. At the same time, I find most Wrox books dry and boring, which makes them hard to concentrate on and take in.
    It’s a rare talent to be able to present technical information in an informative and interesting way, I’d love to see you write such a beginners book.

  22. I had a brief read of the C# Yellow book and found the first 4 chapters good (I skim read a lot, I wasn’t applying the same level of care Jon does to his reviews ;))

    I particularly liked that fact that, when hand waving a concept for later, he put in sufficient text to explain, even vaugely, what it was he was waving away. this let a warm fuzzy feeling of not being talked down to, and that the author knew what he was talking about (rather than just trying to dumb down regardless). Of course that may not be the same reaction a newbie gets.

    It is definitely a book for programming newbies, but frankly that’s likely a good thing.

    I also like his focus on getting a spec, though I’d like to see even more rigor on it. Perhaps in a later section he might. Some of Eric Lippert’s stack overflow uber-answers (such as the one on rounding) where he breaks it down in English first, then the code just flows from that would I think be brilliant additions to an introductory book.

  23. I bought this book thinking about it as an index, helper about essentials and mostly because of the WPF which takes an important part of the book. My disappointment was almost immediate when I came across an example that is just wrong:

    ArrayList MyAL = new ArrayList(10);
    MyAL[2] = “Hello”;

    and also the author states that the next 2 lines are equivalent:

    MyAL.Add(“World”);
    MyAl[MyAL.Count -1] = “World”;

    the page is 370 and this is the very 1st example I read and tried, so…

  24. @J. Ilyev: Yes, that’s definitely a broken example, and one I missed in the errata. I’ll add it when I get a moment.

Comments are closed.