|
|
|
Writing Bug-Free C Code
A Programming Style That Automatically Detects Bugs in C Code
by Jerry Jongerius / January 1995
|
|
|
|
Chapter 9: Conclusion
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-2013 Jerry Jongerius
This book was previously published by Person Education, Inc.,
formerly known as Prentice Hall. ISBN: 0-13-183898-9
|
|
· 