?? preface.html
字號:
<html><head><title>Writing Bug-Free C Code: Preface</title></head><body><center><font size="+3">Preface</font><br><a href="index.html">Writing Bug-Free C Code</a><br></center><br><center><table><tr><td valign=top><small><a href="#quickoverview">Quick Overview of the Book</a><br><a href="#howstarted">How It All Started</a><br><small></td><td width=30> </td><td valign=top><small><a href="#contactauthor">Contacting the Author</a><br><a href="#acknowledgments">Acknowledgments</a><br></small></td></tr></table></center><br><br><table width="100%" border=1 cellspacing=0 bgcolor="#FFFFE0"><tr><td><b>Note to this online book:</b> On April 29, 2002, I reacquiredthe publishingrights to my book (from Prentice Hall; published in January 1995), and havedecided to publish it online, where it is now freely available foranyone to read. The book is showing its age, but for people whostill program in C, the techniques described in thisbook are still a 'little gem' worth knowing about. Enjoy! - <i>Jerry Jongerius</i>, <a href="mailto:jerryj@duckware.com">jerryj@duckware.com</a></td></tr></table><br>This book describes an alternate class methodology that provides complete data hiding and fault-tolerant run-time type checking of objects in C programs. With it, you will produce code that contains fewer bugs. <br><br>The class methodology helps to prevent bugs by making it easier to write C code. It does this by eliminating data structures (class declarations) from include files, which makes a project easier to understand (because there is not as much global information), which makes it easier to write C code, which helps to eliminate bugs. This class methodology, which uses private class declarations, is different from C++, which uses public class declarations. <br><br>The class methodology helps detect bugs by providing for both compile-time and run-time type checking of pointers (handles) to class objects. This run-time type checking catches a lot of bugs for you since invalid object handles (the cause of a lot of bugs) are automatically detected and reported. <br><br>We have all, at some point in our programming careers, spent several hours or days tracking down a particularly obscure bug in our code. Have you ever stepped back and wondered how following a different programming methodology might have prevented such a bug from occurring or have automatically detected it? Or have you tracked down the same type of bug several times? <blockquote><table bgcolor="#E0E0E0" border=1 cellpadding=2 cellspacing=0><tr><td> The key to eliminating bugs from your code is learning from your mistakes. </tr></td></table></blockquote>I have had my fair share of bugs, but when one does occur, I immediately try to institute a new programming methodology that helps prevent and/or automatically detect the bug. That is what this book is all about. It documents the techniques that I use to write virtually bug-free code. You may not agree with 100 percent of the techniques I use and that is OK and only fair, since every programmer has his or her own style. Where you do disagree, however, I challenge and urge you to come up with an alternate methodology that works for you.<br><a name="quickoverview"><br></a><big><b>Quick Overview of the Book</b></big> <br><br>The examples in this book were taken directly from a large production Windows application. Because of this, some of the names you will find are tied to the environment in which the program resides. However, I prefer to show you code taken directly from a real-life production application rather than code that has been made up simply because this book is being written. <br><br><a href="chapter1.html">"Understand Why Bugs Exist."</a> Chapter 1 explores why I think bugs exist in programs today. This is the first step in writing bug-free code. How can we hope to eliminate bugs from our code unless we understand how they come to exist? <br><br><a href="chapter2.html">"Know Your Environment."</a> In order to implement your own programming methodologies that detect bugs, it is important to fully understand your programming environment. Chapter 2 examines the C language and preprocessor in an attempt to show you something new about your programming environment, even if you have been programming in C for many years. For example, did you know that <tt>buffer[nIndex]</tt> is equivalent to <tt>nIndex[buffer]</tt>? Chapter 2 also contains a few programming puzzles to get you thinking about your programming environment. <br><br><a href="chapter3.html">"Rock-Solid Base."</a> Chapter 3 stresses the importance of coding upon a rock-solid base. Without a bug-free base to code upon, how can you be expected to write bug-free code? Chapter 3 suggests what should be done. <br><br><a href="chapter4.html">"The Class Methodology."</a> The class methodology is the key to writing bug-free code and is described in Chapter 4. The class methodology allows complete data hiding and fault-tolerant run-time type checking of objects in C. It accomplishes complete data hiding by moving data declarations out of include files and into the one source file that needs the declaration (very much unlike the public class declarations in C++). The breakthrough to this class methodology is that pointers (handles) to objects of a class can be type checked by the compiler in other source files that use the class but do not have access to the data declaration. <br><br><a href="chapter5.html">"A New Heap Manager."</a> The heap manager that comes with C does not detect programmer bugs. Chapter 5 shows how to create a heap manager that is rock-solid. In addition, the heap manager is needed to support the class methodology. <br><br><a href="chapter6.html">"Designing Modules."</a> Now that everything is in place for writing bug-free code, how should a module be designed? Chapter 6 shows that the key to designing and coding modules is to always code what to do, not how to do it. <br><br><a href="chapter7.html">"General Tips."</a> Chapter 7 contains a variety of tips for writing bug-free code. For example, a key to writing bug-free code is learning from your mistakes. Also, designing stack trace support into an application allows you to track down problems without having to reproduce the problem. <br><br><a href="chapter8.html">"Style Guide."</a> Chapter 8 describes the style that I use to write C code. While every programmer has his or her own way of coding, I feel it is important that a style guide exist in written form. <br><br><a href="chapter9.html">"Conclusion."</a> Chapter 9 contains concluding remarks. The class methodology and run-time type checking are key features presented in this book. <br><br><a href="appendix.html">"Code Listings."</a> This appendix brings together all the code presented in the book into one convenient location.<br><a name="howstarted"><br></a><big><b>How It All Started</b></big> <br><br>It all started when I was a sophomore in high school. Back then, I was introduced to an Apple II computer and was completely amazed by what the computer could do. The Apple had great graphics with plenty of games and educational software. I began to wonder how all the magic was accomplished. <br><br>It wasn't long before I wrote my first BASIC program. Shortly thereafter, however, I encountered my first bug. The only tools and resources available were the computer, the computer manuals and myself. Those were trying times. It taught me to think things through before jumping into coding. <br><br>In my probing around into how the computer worked, I quickly came across something called assembly language and the command CALL -151 (the equivalent of DEBUG for the PC, but in the Apple II ROM). The speed at which programs executed in relation to BASIC was remarkable. At that time, all my assembly language programming was done by hand. The assembly program was entered by typing in the hex digits of the opcode and operands. To this day I still remember a lot of opcodes even though I have not coded in 6502 assembly for many years. I quickly realized the benefits of designing a piece of code before writing it because making any changes essentially meant rewriting the entire assembly program. Later, I purchased an assembler. <br><br>My quest for finding out how the computer worked has never ended. I disassembled (reverse engineered) and commented the entire Apple II Disk Operating System (DOS 3.3 at that time), the bootstrap ROMs and parts of the BASIC interpreter ROMs. I started writing programs that performed disk protection, added keyboard buffers, and so on -- in other words, systems programming. <br><br>Today, I am working on an 80486 66-MHz DX2 with 32 megabytes of memory, local bus video and 600 megabytes of hard disk space -- quite a change from a 1-MHz, 64 kilobytes of memory, 140-kilobyte floppy disk drive Apple II. The hardware has changed drastically, but the methodologies used to write programs haven't changed as fast. The quality of code certainly hasn't improved by several orders of magnitude. <br><br>After college, I started working at Datametrics Systems Corporation, a firm specializing in the performance of Unisys mainframes. Their goal was to produce a top-of-the-line performance monitoring package that ran under Microsoft Windows. A year later, that goal was realized with the release of ViewPoint 1.0. ViewPoint as it stands today is now approximately a quarter million lines of code and very stable. <br><br>ViewPoint originally started out under Windows 1.0. Shortly thereafter, Windows 2.0 was released. Since then, Windows 3.0 and now Windows 3.1 have become mega hits in the PC industry. <br><br>The great thing about Windows 3.0 was that programming bugs could be caught much quicker than before because programming errors caused a general protection fault instead of just trashing memory and more than likely hanging the PC. This is because under pre-3.0 Windows, programs had full access to all the memory in the PC, even memory of other processes. So a bug could trash anything and usually would. Windows 3.0 supported protected address spaces. Therefore, an access to a random memory location most likely would be detected (the infamous UAE, Unrecoverable Application Error) by the operating system and your program halted. <br><br>When I converted ViewPoint to Windows 3.0, it ran the first time. The protected-mode architecture turned up no programming bugs, not a single one! In fact, the ViewPoint 1.0 binary, which was targeted to Windows 2.0, a non-protected OS, can still be run under Windows 3.1, a protected OS, without any problems. This indicates that the program contains no invalid memory references and indicated to me that the programming methodologies that were used to write ViewPoint are valid. <br><br>In the last few years, the programming industry has moved from procedural programming to object-oriented programming (OOP). However, OOP alone does not solve the underlying quality control problems facing the industry. OOP alone does not make you a better programmer. <br><br>I wrote this book to document the programming methodologies that I have used to write ViewPoint under Windows. The methodologies were designed and developed using Microsoft C5 through C8. Since the introduction of Microsoft C/C++ 7.0, the code has been ported to compile under C++.<br><a name="contactauthor"><br></a><big><b>Contacting the Author</b></big> <br><br>If you have any comments on this book, I would like to hear them. I can be reached through the Internet at <a href="mailto:jerryj@duckware.com">jerryj@duckware.com</a>.<br><a name="acknowledgments"><br></a><big><b>Acknowledgments</b></big> <br><br>Special thanks to P.J. Plauger for taking the time to listen to a first-time book author. Your help is greatly appreciated and invaluable. <br><br>I would like to thank everyone at Prentice Hall who helped to make this book a reality, especially Paul W. Becker and Patti Guerrieri. <br><br>Thanks to John Kelly, the president of Datametrics Systems Corporation, for allowing me to write a book that discloses the programming techniques that I developed at Datametrics Systems Corporation. <br><br>Thanks to Jim Kelliher, who provided feedback throughout the entire book writing process. Thanks to John McGowan, who provided feedback on the class methodology. Thanks to John Dripps, who helped during the early stages.<br><br><hr><center><small>Copyright © 1993-1995, 2002-2003 Jerry Jongerius<br>This book was previously published by Person Education, Inc.,<br>formerly known as Prentice Hall. ISBN: 0-13-183898-9<br></small></center></html></body> ?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -