Writing Bug-Free C Code
A Programming Style That Automatically Detects Bugs in C Code
by Jerry Jongerius / January 1995
<< Previous Index Next >>
Chapter 9: Conclusion

9.1 The Class Methodology
9.2 Run-Time Type Checking
  9.3 Isolating Change through Macros
9.4 The Learning Process Never Stops

The class methodology (Chapter 4) is the core methodology described in this book. It makes writing C code easier because it solves the information overload problem that occurs when too many data structures are declared in include files.

9.1 The Class Methodology

The class methodology moves data structure declarations out of include files and places them instead in class implementation modules. Data structures are never accessed directly by code that uses a class. Instead, data structures are turned into private objects that are controlled by calling method functions -- functions that create, manipulate and destroy an object.

All the code that manipulates an object is now isolated into one source file (or module). This leads to a program that consists solely of a number of well-isolated modules. Such a program is easy to enhance and maintain, since changing the implementation of an object involves only code changes in one source file.

The method function names are specifying what to do, not how to do it. For example, DosWriteFile(hDosFh, lpMem, wSize) is specifying that we want to write some information to a file. The how is left up to DosWriteFile().

Applying the class methodology to a program is a deceptively simple thing to do, but it is a powerful concept when applied to an entire program.

9.2 Run-Time Type Checking

If all method functions of a class employ run-time type checking on pointers (handles) passed into the module, a lot of common programming errors will be detected automatically and reported.

When combined with full symbolic stack traces at the point of failure, almost all problems can be deduced from the symbolic stack trace and fixed. A problem does not have to be reproducible in order to track down the problem.

9.3 Isolating Change through Macros

Over the years, the class methodology has undergone a lot of changes in how it is implemented. However, through all these changes, the code base has changed little.

The macros that were used in the source code specify what to do and not how to do it. For example, the NEWOBJ(hObj) and VERIFY(hObj) macro syntax has stayed the same, but the implementation of these macros has changed drastically.

The key is to pick the correct what (or interface). If done correctly, the what can stay the same and the how can change drastically.

9.4 The Learning Process Never Stops

Writing bug-free C code takes a lot of effort. It is not something that just happens. You could have all the latest whiz-bang tools and languages, but they do not help you to write bug-free code unless you have a thorough knowledge of the tools and languages themselves.

Consider a carpenter's tools. If you were given all of the carpenter's tools, could you build a house? Of course not. Why? Mainly because you do not have the knowledge of how to use the tools. The same goes for programming and writing bug-free code. How can you be expected to write quality code unless you know your tools inside out? No matter what skill level you are at, there will always be something new to learn because the learning process never stops. I am amazed that even after years of programming in C I am still learning new nuances about the language.

I have no doubt that the techniques described in this book will continue to be refined. I would be disappointed if they were not. They are just a snapshot of the techniques that I use today, techniques that have been refined over many years of programming in C.

I hope you have learned from my techniques something new about writing bug-free C code.


Copyright © 1993-1995, 2002-2024 Jerry Jongerius
This book was previously published by Pearson Education, Inc.,
formerly known as Prentice Hall. ISBN: 0-13-183898-9