Spotlight customer reviews:
|
Customer Rating: 
Summary: Excellent
Comment: Framework Design Guidelines offers a wealth of information that is presented in a format that is easy to understand and offers insights from various developers at Microsoft. Comment boxes are sprinkled throughout the book, written by Microsoft .NET team members and other expert developers in .NET. Sometime one, but often two, three of four comments will follow a core concept in the book. They offer up insights, criticisms and great real-world examples of how the design guidelines have helped the .NET, and where ignore them hurt .NET. To me, this communication directly from the actual developers who wrote numerous classes in the 1.0, 1.1 and 2.0 releases is great. And sometimes they will disagree on a point, which really provides insights into when and how you should follow the guidelines.
I am already starting to present ideas from this book to my team at work. This will influence our next product release in a very good way.
Customer Rating:
Summary: Recommended for all .NET developers
Comment: Yes, the title's a mouthful, but it's also well worth a purchase. Although it's generally focused on helping you develop public APIs (i.e. those that are going to be exposed to customers or other teams), it's also a superb reference if you just want to know the correct methodology behind many aspects of .NET development, such as the best method to use when handling exceptions for example.
Common to this book and the Standard Library Annotated Reference titles (also published by Addison Wesley) are the comments from developers, experts and the original authors of the .NET framework themselves, interspersed throughout the main text. These little gems help split the text up, give background details on certain features and can even describe how what ended up shipping was actually dead wrong in retrospect. They're in a conversational style that's refreshing and really aid the understanding of some of the topics. There's even disagreement at times, with annotations appearing one after another, weighing the pros and cons of particular approaches. There's always the danger that a title like this could feel overly prescriptive, but that's definitely not the case here.
The main text is well written and the coverage of topics is just right. It never feels like a boring tome; instead there's genuine insight on the majority of pages with no fluff to speak of. The guidelines themselves come split into Do, Do Not, Avoid and Consider forms, where the first three are strong recommendations and the Consider is a guideline that applies the majority of the time, but is looser than the others. The guidelines always have supporting code examples and, although I thought I was a reasonable .NET programmer, I found myself learning a great deal about how to code correctly against the framework and how to better design my classes, both internal and those that will get used by others.
The book also includes suggested naming conventions (which is always a near religious thing in developer circles, and which I found myself disagreeing with at many points), a sample API design for the .NET 2.0 Stopwatch class (which is great, but all too brief) and a bit of a pointless guide to FxCop, which feels a little like filler material. At around 300 pages, the book is accessible (i.e. you're not going to break your back hefting it around the office), but you're better off picking up the title from Amazon.com where it's significantly cheaper than getting it from the UK site (at $24 instead of a rip-off £28.50).
Completing the package is a DVD with code samples, the exact same Stopwatch API review (why?), and quite a few lecture videos from the people who wrote the book and other .NET luminaries like performance whiz Rico Mariani (who talks very fast, like it's costing him valuable cycles to include any space between his words!), FxCop dev Michael Murray and Steven Clarke.
This one's a keeper.
Customer Rating: 
Summary: Can help improve your API design
Comment: The book is essentially about designing good API based on the lessons learned when designing the .NET Framework. A good knowledge of the CLR is assumed and in particular C#. Most of the examples are in C# syntax with some in VB.NET. The book takes what could be very dry material and makes it more interesting and useful with real examples from the current CLR and anecdotal information from various well known names in the .NET world.
There are 9 chapters and 3 Appendices with information on style conventions, the FxCop tool and a sample API.
The first 7 chapters are well-structured and very readable, even start-to-finish. They can also be easily used as reference material focusing on specifics such as naming guidelines, type and member design and exception class design. The last two chapters cover general usage guidelines and common design patterns. These topics are very broad and consequently the chapters feel more like summary info and don't go into much depth. Picking up some titles from the suggested reading list is definitely recommended to augment these chapters if you are interested in more detail.
Overall the book is readable and straightforward and should help anyone writing .NET libraries produce more usable APIs. Certainly the guidelines are mostly covered by FxCop but the additional information around the 'why' for the rules should help you fix the violations in the right way.
Customer Rating:
Summary: Excellant Work!!
Comment: This book is not just for people developing frameworks but also for Application programmers who use frameworks. If you donot know how frameworks are designed then you wont be really efficient in using it.
I also use thier Naming Guidelines in our software development team just to create a standard. Overall a class work. Kudos to Brad et al.
Customer Rating:
Summary: A unique work on .NET API design
Comment: It's not often that I see a book like this, and I do so with pleasure. This book covers best practices in developing frameworks and APIs for .NET. And it comes from a variety of different sources and perspectives. There is excellent pragmatic advice in here and it's worth a read even if you aren't doing .NET.
|
|
|
