Effective C Sharp 50 Specific Ways to Improve Your C Sharp | Date: 19 January 2011, 08:15
|
Introduction: Effective C# Effective C# Introduction This book is the result of all the questions I ve answered for readers, consulting clients, and at various .NET user group meetings. Effective C# is not an introduction to the C# Language, or .NET programming. Rather, this book is meant for professional C# developers that are interested in becoming more productive with the C# language. With that in mind, throughout the book I assume that you have some working knowledge of C#, and the core .NET Framework. This book will show you the techniques that experienced C# programmers always use, or almost always avoid. We follow these practices because we ve learned. We ve learned the hard way, by fixing our own code when we didn t follow these practices. Or, we ve learned the easy way, by listening to the advice of others. This book is your chance to learn the easy way. With a great deal of help (and some argument) from a fantastic group of colleagues and technical reviewers, this book shows you the techniques we follow and why. In each item I give you a specific piece of advice that the best C# programmers use, and explain the rationale behind that advice. This book is not a how-to, or a cookbook that contains large volumes of sample code that produces particular features. You will not find sample programs that you can use for your particular programming tasks. In fact, I have tried to limit the length of each code listing to better highlight the techniques I am illustrating in that item. I started writing C# programs after spending close to ten years developing C++ programs. I know the switch from native, unmanaged development to a managed environment was one of the biggest adjustments I made when I started working with C#. To that end, I m certain that some of the advice in this book is colored by that experience. Those items might seem obvious to a reader with a strong Java background. But, it s clear to me from working with the C# community that developers come to C# from different backgrounds: VB 6 (or earlier), Java, and C++ developers comprise the largest segments. I tried to keep the advice centered on C# and the .NET environment and away from migrating from one particular language to another. My goal was to write Effective C# so that no matter what path brought you to the C# language, this book will help you do your best development, now that you are here. Nomenclature The biggest difficulty writing a book about a programming language is that language designers take real English words and give them a very specific new meaning. It makes for passages that can be tough to understand: "Develop interfaces with interfaces," as an example. Anytime I use a specific language keyword, it is in the code style. When I discuss general topics with specific C# concepts, the specific C# topic is capitalized, as in: "Create Interfaces to represent the interface supported by your classes." It s still not perfect, but it should make many of these passages easier to read. re> There are many related C# terms used in this book. When I refer to a member of type, it refers to any definition that can be part of a type: methods, properties, fields, indexers, events, enums or delegates. When only some apply, I use a more specific term: property, method, data field, delegate. Finally, there are a number of terms that may or may not already be familiar to you. New terms appear in bold for the first time. Code Conventions The code samples in this book are small, focused examples that illustrate one technique, or the pitfalls associated with not following the recommended technique. I ve omitted many details from each listing. In most cases, you should assume the presence of common using clauses: using Systm;using System.IO;using System.Collections;using System.Data; re> Omitting these saves us both time: I did not have to write these at the top of every sample. You don t have to read it at the top of every sample. When I use less common namespaces, I make sure you can see the relevant namespace. I use fully qualified class names in very short samples. I include the less common using statements in larger samples. I take similar liberties with code inside the samples. For example, I ll show this: string s1 = GetMessage( ); re> However, I may not show the body of the GetMessage( ) routine if it s not relevant to the discussion. Whenever I omit code, you can assume that the missing method does something obvious and reasonable. My purpose in this is to keep us both focused on the particular topic. By omitting code that is not part of that topic, neither of us gets distracted. With those omissions, you will not be able to type the code samples and get a running sample. However, all the code is syntactically correct. A Word about advice and goals Your design goals have a strong bearing on how best to implement a solution to a particular problem. In most situations, decreasing development time is the primary goal. Some applications, notably compact framework applications, will consider space the primary goal. Scientific and Engineering applications will place the highest premium on the overall performance of the system. Still other times, it s scalability. Depending on your goals, a particular piece of advice may be less relevant. In those cases, I have explained the goals in detail so that you can decide when it applies to you. For example, whether or not to use ADO.NET Datasets has generated much debate in the .NET community. I, for one, believe using them is a great timesaver. Others I highly respect, such as Ted Neward and Clemens Vasters, disagree. It depends on what you re building. I take my position because it saves me time. Both Ted and Clemens write a great deal of software that transfers documents between .NET and Java based systems. Datasets are a bad idea for those systems. Before you blindingly follow my advice, or anyone s for that matter, understand why the advice is there and make sure the justification matches your goals. I ve given the justification on all the guidelines in the book. Of course, some guidelines are universal, because they affect the correctness of your program, such as initializing data members properly. In those cases, I usually omit the obvious justification, which is that your program won t work otherwise. What about C# 2.0 You ll notice that I say rather little about the upcoming C# 2.0 release. There are two reasons for this. First and foremost, most of the advice in this book will apply just as well for C# 2.0 as it does now. C# 2.0, while a significant upgrade, does not invalidate most of today s advice. Where the best practices will change, I ve noted that in the text. The second reason is that it s too early to write the most effective uses of the C# 2.0 features. As I stated in the beginning of the introduction, this book is based on the experience I ve had, and the experience my colleagues have had, using C# 1.0. None of us have as enough experience with C# 2.0 to know the best ways to incorporate the new features into our daily tasks. I d rather not mislead you and act like I have the answers when the simple fact is that the time to cover C# 2.0 in an Effective book has not yet arrived. Providing Feedback This book is based on my experiences, and many conversations with colleagues. If your experience is different, I want to know about it. Please contact me via email: [a rel="nofollow" target="_blank" href=""mailto:wwagner@srtsolutions.com"">wwagner@srtsolutions.com I ll be posting those comments online as extensions to the book. See
|
DISCLAIMER:
This site does not store Effective C Sharp 50 Specific Ways to Improve Your C Sharp on its server. We only index and link to Effective C Sharp 50 Specific Ways to Improve Your C Sharp provided by other sites. Please contact the content providers to delete Effective C Sharp 50 Specific Ways to Improve Your C Sharp if any and email us, we'll remove relevant links or contents immediately.
|
 |
|
Comments (0)
All
