Effective C#

Jim Holmes writes "I'm new to the .NET environment and have been looking for solid books in the same class as McConnell's Code Complete, 2nd ed., or Kernhigan and Pike's The Practice of Programming. Those books, to me, are must-haves on any serious developer's bookshelf, but while they're terrific books, they're general in nature. Bill Wagner's book Effective C# is a great companion to those books because it's specific to C# and hits hard the implementation details of working in that language. (Disclaimers: 1) I got this book for free from Addison-Wesley as a regular giveaway for our .NET Developers Group. 2) I attempted to get SRT Solutions, the author's consulting company, involved in a software development project several years ago. The project tanked due to customer constraints and other business issues not related in any way to Wagner or his company. End Disclaimers.)" Read on for the rest of Holmes's review. Effective C#: 50 Specific Ways to Improve Your C# author Bill Wagner pages 336 publisher Addison Wesley rating 9 reviewer Jim Holmes ISBN 0321245660 summary Must-have addition to any serious C# developer's bookshelf

If you're interested in, or currently working with, .NET and are tempted to skip past this book as Just Another C# Reference Book, think again. Wagner's book is a great resource because it covers concepts which run across the entire .NET Framework regardless of which language you're working with. While this book focuses on C#, VB.NET developers can benefit from some of the text within as well.

I also think this book speaks to a wide range of readers. Seasoned developers will blow through this content, fine-tuning their coding methods or starting new ones. Wagner specifically points out how practices experienced C++ developers may use aren't good practices in C#, such as avoiding function call overhead by writing longer C# methods with more convoluted loops. More on that later.

New developers also can greatly benefit from this book by using it to properly form development habits early in their careers. Examples of this might include following Wagner's recommendations for safe casting, strong use of interfaces, and knowledgeable resource management.

Wagner's writing style is clear and concise. He occasionally comes across as brusque, or as writing only to experienced developers ("I wouldn't write code like this and neither would you."), but those instances are few and far between. The rest of the book's voice is terrific. More important is the weight of Wagner's knowledge and experience.

One real drawback is a large number of typographical errors, sometimes several per chapter. Some sentences are missing content, and there are a large number of run-together words. These errors don't take away from the material, but it's an annoyance all the same. I would have expected better proofreaders at AW.

The book is well organized into six chapters, each hitting a specific area in C#. Within each chapter, Wagner covers six to ten items, each item focusing on one specific "minitopic," as Wagner calls them. Each item includes code snippets to demonstrate recommended approaches. Few of Wagner's snippets will function as standalone programs, but this is an advantage, as I see it. The book focuses on tight, specific examples, rather than weighing itself down with pages of extraneous fluff.

Often Wagner's recommended approach is contrasted against bad practices, or practices which might be optimal in other languages but work poorly in C#. An example of this would be Chapter 4's Item 31: "Prefer Small, Simple Functions," where Wagner shows how smaller functions are generally more efficient than larger functions with complex loops. This probably confounds experienced C++ developers, but it's a prime example of how valuable this book is. Wagner shows that .NET's Just-In-Time compiler pays less cost when calling functions than it does trying to wade through convoluted loop logic. His recommendation? Write "the clearest code you can create. Let the JIT compiler do the rest."

Chapter 1, "C# Language Elements", hits hard the topics "you must remember every day when you write C# code." This chapter discusses issues central to C#'s syntax, implementation and optimization. Wagner talks about basic Object Oriented concepts such as hiding class data members behind Properties (.NET's common access methods/fields via gets and sets), and why it's important to implement a ToString() method. Basic software engineering topics are also covered, like why it's important to differentiate between value and reference data types -- and the pitfalls of failing to do so. This chapter also thrashes out coverage on deep C# concepts like why developers should use foreach loops and why the GetHashCode() method will "practically always get you in trouble."

Chapter 2, ".NET Resource Management", has a lot of text on general patterns for constructing optimal code. Wagner's in-depth knowledge of the .NET Framework's underpinnings really shows through here. There's a very clear discussion of the performance ramifications of boxing (wrapping value type data into an object for method parameters) and unboxing. Minimizing extra garbage (unnecessary objects) and easing resource clean up via standard dispose patterns are also covered. This chapter's critical to ensuring you understand what's going on with resources in your .NET application.

Chapter 3, "Expressing Designs with C#", looks at object-oriented design in C#. While the discussion's specific to C#, there's a lot of great, practical information which applies to any object oriented development. Wagner gives some great examples with backup discussion regarding preferring the use of interfaces over inheritance and why it's a cleaner solution. (Java programmers who've read Alan Holub's "Why extends is Evil" in JavaWorld would enjoy this section.) There's also great treatment of using delegates for callbacks, and events for outgoing interfaces. Wagner also points out more pitfalls in a reference data type language: returning references to internal class objects via a read-only property (getter for Java folks).

Chapter 4, "Creating Binary Components", shows what critical topics you have to consider when creating even a moderately complex system for deployment. Wagner exposes some terrific details on how smaller is better when developing .NET assemblies for deployment. He also discusses why it's best to limit a class's exposure through public scope since this ends up advertising too much of your class's internals to potential users of that class. Wagner ties this back to interface discussions in earlier portions of the book, and makes a good case in this section for bad scope's impact on deployment.

Chapter 5, "Working with the Framework", delves into the .NET Framework Class Library. The FCL is a huge library and Wagner's insistent that too many developers are writing custom code for functionality which already exists in the FCL. This section helps to avoid having "developers reinvent the wheel." There are very useful discussions on using .NET runtime diagnostics, .NET's validation capabilities, and standard configuration mechanisms. Wagner also shows why .NET's reflection capability (one component dynamically discovering another component's capabilities at runtime) can be overused - but he also shows how to best use it in the appropriate cases.

Chapter 6, "Miscellaneous", is the catch-all section. Security and exceptions are covered here, as is the pain of working with COM interoperability - and why you should avoid it if at all possible. Just as importantly, Wagner points to several tools which should be in any C# developer's belt. He also identifies terrific resources available online.

What makes this book so useful is that Wagner constantly talks about the reasons behind why specific choices in C# should be made. For example, in Item 3, "Prefer the as and is Operator to Casts" Wagner moves through the rationale of why a developer should (when possible) avoid casting in C# and use the as and is operators instead. Casting can lead to headaches with data loss when casting a long data type to an integer one, or more headaches with the extra lines of code to ensure the cast was to a proper type. Sure, casts are sometimes necessary, and it's another value point for this book that Wagner gives clear examples of when his techniques don't apply -- and he also shows recommended alternatives for those cases.

It's just this kind of discussion from an experienced developer that makes this book so valuable. Good developers need to understand the ramifications of choices they make designing and implementing a system. Wagner's book is outstanding for exactly this kind of detailed, clear exposition.

An additional bonus: Wagner has a blog dedicated to discussion of items from his book. Erata are also listed there. See Bill Wagner's Effective C# blog.

The bottom line: this book really is a critical addition to a serious C# or .NET developer's bookshelf. It deserves a place right alongside books from McConnell, Macguire, Kernighan and Pike.

You can purchase Effective C#: 50 Specific Ways to Improve Your C# from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

So Call Me Old And Cranky

[DanielMarkham]

"..in the same class as Code Complete"
But do we really need a "programming good C#" book? Isn't good programming all about, well, good programming? If I remember Code Complete correctly, it used pascal and C, I think. It definitely was one of the best books I've read, but how many times can you say the same thing over and over again?
Languages come and go. But good coding techniques don't dependent on a certain vendor or technology.
Maybe this is a good book if you don't know much of any programming language and want to pick up C#. Speaking as a C# developer who does Java, C, C++, and VB, I just read some of the rags and jumped in. Then when I wanted to do something else, like create a custom web control, I got a book in C#. Presto/Bingo, I'm coding in C#. OOP as a concept is going to have similar constructs, no matter what the language, right?
Sorry for the rant. It's probably a great book. I just don't understand how good coding practice is dependent on the flavor-of-the-week. Perhaps in his comparisons the reviewer does a disservice to the intent of the work.

Re:So Call Me Old And Cranky

[zhiwenchong]

Now, I'm not saying the above book is good (haven't read it, probably won't), but I do see the value of a book telling you about the best practices in the particular language you're interested in.

You know, I would venture to say not all programming concepts are necessarily always universal. That's because programming languages are abstractions, and abstractions can vary vastly.

Take an elementary operation: You might say a for loop is a for loop, but in languages like LISP we tend to use recursion.

In MATLAB, we tend to avoid for loops whenever we can; instead we vectorize and operate on the vector instead.

Most of the common constructs that we know have been shaped by ALGOL, but when you need to write something sophisticated in say, a declarative language, you pretty much have to think in a different way.

The difference in paradigms between C# and languages like C++ may be much smaller, but I can tell you, you'll find it easier to wrote good code in C# as long as you stop thinking in C++ and start thinking in C#. (I've tinkered with C# and I like a lot of ideas that are in it)

Recently I switched from perl to python for my text-processing needs, and I found that I had to switch my mindset completely, even though both languages weren't too different on the surface. I found that Python were optimized for different things than Perl.

Many people dismiss programming languages as merely different syntaxes for expressing the same ideas, but let's consider this quotation from A.N. Whitehead (co-author of Principia Mathematica, written with Bertrand Russell):

"""By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and, in effect, increases the mental power of the race. Before the introduction of the Arabic notation, multiplication was difficult, and the division even of integers called into play the highest mathematical faculties. Probably nothing in the modern world would have more astonished a Greek mathematician than to learn that ... a large proportion of the population of Western Europe could perform the operation of division for the largest numbers. This fact would have seemed to him a sheer impossibility ... Our modern power of easy reckoning with decimal fractions is the almost miraculous result of the gradual discovery of a perfect notation."""

-- A.N. Whitehead, An Introduction to Mathematics, 1911

I got this quote from Code Complete, btw. ;-)

Re:Meanwhile...

[AuMatar]

Except for the vast majority who aren't even considering it. I don't know anyone who has even been asked to look at C#, I know plenty of people doing C++ and Java. But keep reading the MS press releases and believing that, its amusing to people who actually follow industry.

Design Patterns are the symptom of a problem

[team99parody]

The usefullness of Patterns is really just a symptom that you're not solving the right problem or using the wrong tools.

Paul Graham said it best:

For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

He goes on to reference Norvig's paper Design Patterns in Dynamic Programming that points out that in more productive environments, many if not most of the classic "design patterns" are totally invisible in better platforms today.

If you are spending a lot of code writing stuff that fits nicely into design patterns, you'd be far better off switching to a platform (any lisp platform; any python platform; ruby/rails) that frees you from this redundancy automatically.

Re:from the oxymoron dept...

[BAILOPAN]

I know you were trying to be funny, but from a C# programmer's perspective, you're just being ignorant.

C# is an advanced, well thought-out OOP language. When coupled with the .NET platform, it's easy, flexible, and powerful. Academia was pretty quick to gobble up Java but I've seen more and more schools replacing VB/Java courses with C# lately.

It's an open standard, despite what people may think, and as Windows.Forms becomes implemented on other operating systems, adoption will spread. Microsoft even released the source code to a FreeBSD CLR implementation called "Rotor".

Remember, just because it's from Microsoft doesn't automatically negate it ;)

Re:from the oxymoron dept...

[compass46]

Hmmmm, I barely knew the name of the FreeBSD specific CLR implamentation. I don't think anyone seriously uses Rotor or has developed it in the past 2.5 years.

(This brought to you by one of FreeBSD's Mono port maintainers. ;)

Wow, look at all the MS haters ...

[Chitlenz]

C# is a GREAT language, this is coming from a long history in Oracle/Unix/Linux. I don't understand where people got the idea that it won't work on Linux either. We're coding 3-monitor full screen 3d MRI analysis applications in it, and I can assure you that it has accelerated our developement time over the last iteration created with Borland C++ Builder. Ironically, it took 8 years to write the last version of our software in Builder, and 6 months to completely rewrite it with enhancements in c#. That, consequently, was with both the lead developers having no experience with the language (I was a C++ folk, and he'd been using Delphi, so we settled on C# since it was essentially the next evolution of Delphi).

It's no joke, and I'll be buying this book just to have it. I've also picked up most of the Deitel series of books on c#, and of course the O'reilly books. The c# cookbook is another GREAT reference. Anyone interested in starting with C# should check www.codeproject.com for examples. Also, along with a rude admonishment to the MS haters for not having researched the topic (MS dependant indeed), check www.omnicore.com for a native crossplatform compiler for c#. It's cheap too, but doesn't do forms support just yet (when it does, I'll probably move from VS just to get free cross-platform compatability).

-chitlenz

Re:Wow, look at all the MS haters ...

[Chitlenz]

There were several poorly implemented replication features that more seamlessly worked within .NET for whatever reason. Things have gotten much simpler overall to get the actual applciation to more easily do what what you want it to do. The c++ rewrite had a much longer lead time, we actually knew this since we did start into a rewrite of 2 of our 8 applcaitions (at the time). It's not a question of incompetence, its a question of shortcuts, and .NET has LOTS of them, with 3rd parties adding lots more.

-chitlenz

Re:large functions in c++

[Rakshasa Taisab]

Not only do we avoid paying anything when using inlined functions, but also get really aggressive optimization when using template algorithms. Using std::for_each, std::find_if and friends on containers has become the norm for me, rather than the exception.

It's funny how they hype the features of new programming languages, while they seem to miss what is already in C++. Personally, i can't really take seriously a language without proper template support.

Re:Hah

[AstroDrabb]

.NET is _not_ a "godsend". The Java framework has had all of the .Net framework functionality for a while now, and Java still manages to be cross-platform. The only people that think .Net is a "godsend" are peopel who only know VB and VBScript/ASP.

I am not a .Net hater, I am just an MS hater. Why? Because of the intentional things MS does to stop other products from working. For example, ASP.Net (in C# or whatever) should put out standards compliant HTML, regardless of browser. However, that is not the case. A fellow programming friend of mine who, sadly, grew up in the "MS only camp" made this page. Go to this URL in IE, then under the "Quick. Cheap. Easy." flash, click on Info. Notice that everything looks fine? Now do the _same_ steps, but do them in Firefox/Mozilla. Once you click the "Info" link the page looks like crap. After talking to my friend, it turns out that he used _nothing_ but MS supplied .Net controls. Now, I want you to do a few more experiments (I have already done them and know the outcome). Download and install the User Agent Switcher extension for Firefox. Make Firefox "pretend" to be IE 6 and go back to the link above.!!!!! Wow, the MS ASP.Net framework sends down different HTML depending on whether you are using IE or not! Making Firefox "pretend" to be IE, causes the MS ASP.Net framework to send down IE-Only Code that actually happens to make the site look correct in Firefox.

Now, there is one other experiment for us. Go back to the link as Firefox. Then go under File -> Save Page As and pick Web Page Complete. This option will save all the images, scripts and HTML of the page that was sent to Firefox. Now, open up IE and drag-n-drop the complete HTML or HTM page that you saved from Firefox to IE. Do you notice ANYTHING STRANGE? IE renders the Firefox delivered page just as poorly as Firefox does!

So to sum up my thoughts on MS .Net. I love C#. It is a very nice language. I think the MS .Net framework is very nice. However, I also hate the MS .Net framework because it is designed for crap MS only. For all of the ASP.Net/C# Web apps I have made, I have had to actually _fight_ against the MS Visual Studio IDE to force it to make standard compliant web apps. It seems that the latest versions of MS Visual Studio IDE just want to produce IE/MS only web apps. To me that is not acceptable. I personally would rather stick to Java/Servlets/JSP or PHP and have total control myself, than put up with MS intentionally trying to break non-IE browser.

For all the MS-apologist, please save your excuses. MS could have made there ASP.Net framework deliver the _same_ HTML across all browsers. All MS had to do was make ASP.Net standards compliant, which it is _not_!

Re:from the oxymoron dept...

[chochos]

Actually the Mono team encourages you to stay away from Rotor as if it was the plague, because it's the infamous shared source license. It's all MS code, not open source at all. So if you have looked at the source for Rotor, you shouldn't (or can't? I don't really know) contribute to the Mono framework (or Portable.NET or any other one if there are more implementations) because in the future it might bring patent or copyright issues from MS against those projects. It also supposedly runs on Mac OS X. But you need 1GB free disk space to build the thing. Why? I don't know. Mono doesn't use as much space, and it includes the CLR and the class libraries.

Re:from the oxymoron dept...

[fitten]

It's a shame if more and more schools are picking up C# to learn students how to program. Java is the cleaner one of the languages - take for instance the virtual keyword in C# - not very OO.

Actually, I've heard far more people knowledgable in both languages say the exact opposite as this. Considering C# was developed supposedly to "fix" specific deficiencies in Java and I've seen good rebuttal on both sides with Java coming up on the short end of the stick almost all the time (exception cases are where someone seems to have some devotion to some fringe case that is considered by many to be "bad") and the final recourse of the Java side is to say that it's "open", to which the rebuttal is that it isn't as open as C#.

But the thing that worries me most is the IDE. For C# I know two moderately usefull IDE's: Microsoft and Borlands. Both are commercial (ok, maybe not for students, but you know about indoctrination). So we either have to pay these companies for their environments, or we should use the rather outdated text editors for these purposes.

Others have already replied with free (beer) ones listed.

And then there is the matter of documentation. Excuse me for being blunt, but the .NET documentation is not that great. It consists of examples in several languages and things can be pretty difficult to find.

There must be two kinds of people in the world. Those that can use Microsoft documentation very effectively and those who can't. I see a few people claiming that Microsoft documentation isn't that good, but I've been using Unix/Linux since 1986 (computers in general since 1980)and Microsoft products since 1993 and I've always been more than adequately served by Microsoft documentation.

Re:Hah

[code shady]

With regards to the HTML problem, have you considered that it might be because of an outdated segment in your web or machine.config files?

I myself am a C# developer (win forms and web forms), and I initiall had a huge problem trying to test and use any sort of aspx web application in firefox. After poking around for a bit, it turns out that the .NET framework will generate two different kinds of html one for "uplevel" browsers (by default i think this is only MSIE 5+ and posibly netscape 6 but don't quote me on that last part).

Anyway, there is a section that you can place in you web.config or machine.config files (i assume you know the difference between the two) that details the browser capabilities of various browsers hence the name browsercaps. By default this section of the file is pretty useless, it will detect IE, some netscape and that more or less it. Maybe some mobile browsers for PocketPC as well. This can be updated, and i find that the information at This Link is extremley helpful. I have used the browsercap information from this site on a few production servers to get rid of some ugly issues with AbleCommerce and Firefox, and i have it on my development machine as well; the difference in rendering will suprise you. In short, I highly reccomend that every ASP.NET developer check this information out, and keep your browsercaps section up to date. It may not be a 100% effective solution but it does do an excellent job of getting rid of most of the problems you will have when using a non MS browser.

Re:from the oxymoron dept...

[llamaluvr]

then there is the matter of documentation. Excuse me for being blunt, but the .NET documentation is not that great. It consists of examples in several languages and things can be pretty difficult to find.

The only difficult thing I've found with the .NET documentation is that it doesn't always come up first thing on a google search, unlike javadoc when you're looking up java classes. Other than that, it's great. It provides examples for each class in VB, C#, and C++, clearly marking which one is which. Javadoc generally doesn't provide examples. On difficult-to-use classes, .NET docs have often been my last stop before continuing programming. That has not often been the case w/ javadocs.

Also, a lot of basic descriptions for classes and methods are built right in to the IDE with intellisense, not to mention that the intellisense in VS is simply more "intelligent" than Eclipse's.