Effective C# (covers C# 4.0): 50 Specific Ways to Improve Your C (Effective Software Development) [Englisch] [Taschenbuch]

I have both editions of "Effective C#". The older, first edition did not have lambda expressions, LINQ, or generics (though it hinted at generics towards the end). In the second edition, tips (called "Items") that have since fallen out of practice are weeded out and are replaced with fresh concepts from .NET 2.0, through 4.0.

The items are written in a very clear manner. Most of the figures are illustrative of the concepts. Some of the pictures aren't quite as clear as they could be (.NET's Garbage Collector sticks out in my mind - Bill! read some Tufte! :) but for the most part, each item gave a firm understanding. I could read the first and last paragraph of each item to get a clear bird's eye explanation. Later, I would pore over the details with a highlighter and come away enlightened.

This book has a sister - "More Effective C#". This was released PRIOR to "Effective C# - Second Edition". I own that copy too, and it's dog-eared by now. The two books go together like peas and carrots, though "More Effective C#" touches on more advanced .NET 3.0 concepts. "More Effective C#"'s treatment of "yield return", dependency injection, and composition in the third chapter alone are inspiring.

If you really want to go all out, I'd recommend getting "C# in Depth" by John Skeet. There's a new edition coming out in the summer of 2010. Skeet's book will bring the reader up to speed on the advancements of C# in .NET 3.0 (and soon 4.0) without giving them any specific tips. The "Effective C#" series will give the reader specific tips without bringing anybody up to speed.

Also, the author is a cool guy. I emailed him back in 2009 with questions about the first edition and he brought me up to speed by responding on his blog. You are encouraged to give him feedback.

I consider "Effective C#" as one of the first books I reach when I want to brush up on my skill set.

The Kindle edition uses different font weights so that the text is shown differently from the code.
a) A normal black for the text; and
b) a completely invisible grey for the code.
If you have any desire to actually see the code in this book, don't bother with the Kindle edition.
The conversion was very shoddy.

I should be clear, I am not criticizing this book as being "bad", but it turns out to have been the least useful C# book I've purchased. This is admittedly in part due to my own preferences and perceptions about what I need from various C# books.

There is a quote from Alice in Wonderland that I find quite applicable here:
Alice: Would you tell me, please, which way I ought to go from here?
The Cat: That depends a good deal on where you want to get to.

This quote kept coming to mind as I read through all 50 tips. They aren't really tips so much as, well, good ideas, assuming what the author is describing is what you want to do. If it isn't what you want to do, any given tip is either not applicable, or actually a bad idea.

I found myself thinking, about each tip, one of three things:
1) Well, yes, of course, that's a good best practice. For most of these, I already knew that. The only one that impressed me was using readonly vs const: it was a good overall explanation of how const can backfire.
2) Um, no, that really isn't true, though a lot of people think it is. In particular his discussion of StringBuilder vs string concatenation was much less enlightening than googling for the topic and reading useful forum/blog posts.
3) Um, I guess that's a good idea, assuming that's what you intend to do in the first place. (Most of the book fit into this category for me.)

So I find myself reading tips that are either really obvious, or I believe they're wrong or slightly misinformed, or they really don't apply to anything I need to do at all. The author appears to use C# mostly to write APIs that would be used generally by others, e.g., more on the "web service" side than the "web application" side. If your goal is to write APIs, you may very well find these tips to be much more useful than I do. The tips aren't "wrong", but as I find myself usually writing applications instead of APIs, they don't explain anything that I'd actually use. Other tips discuss architecture decisions that would never come up for the person who is merely responsible for implementing them: this is sometimes useful, but really, architecture decisions are entirely dependent on what you want the application to do (queue the Alice quote again).

I would suggest that his worst tip is the one where he briefly discusses the StringBuilder vs string concatenation debate. The tip is to not create unnecessary objects. This is certainly a valid concern. He doesn't really weigh the advantages/disadvantages, rather he simply asserts that StringBuilder is better because fewer objects are created for the garbage collector to collect. I don't want to belabor the already-well-known-and-easily-googled discussions on the matter, but suffice it to say, the real answer is "it depends". Sometimes StringBuilder is clearly the best choice. Sometimes simple string concatenation is clearly superior (the garbage collector really is very smart about how to handle the extra strings that are orphaned by concatenation, so long as you don't abuse it). And String.Format really isn't all that advantageous, either, unless you need special/complex formatting, because it goes and creates a new StringBuilder (with associated overhead and requiring garbage collection) every time you call it.

"Would you tell me, please, which way I ought to [code] from here?" asked Alice. "That depends a good deal on where you want to get to," replied the Cat.

I would steer those who are looking for expert-level knowledge about how C# "really works" to check out Jon Skeet's "C# in Depth, Second Edition", also available from Amazon. It covers many of the same topics, but I believe it provides a deeper understanding of C# such that you don't need any "specific tips", but rather the correct course of action becomes obvious based on the circumstances at hand.