chapter1.html

Writing Bug-Free C Code

<br><a name="debugger"><br></a>
<big><b>1.5 Relying on Debuggers</b></big>
 <br><br>
Debuggers are great tools, but they are no substitute for good
 programming methodologies that help eliminate bugs in the first
 place.
 <br><br>
Debuggers certainly make finding bugs easier, but at what price? 
 Does knowing that there is a powerful debugger there to help you
 when you get in trouble cause you to design and write code faster
 and test it sooner than you should have, causing a bug that forces
 you to use the debugger?  A bug that would not be there had you
 spent the time in the design and coding phases of the project.
 <br><br>
I personally feel that programmers whose first course of action
 against a bug is to use a debugger begin to rely more and more on a
 debugger over time.  Programmers who use a debugger only after all
 other options have been exercised begin to rely less and less on a
 debugger over time.
 <br><br>
Instead of a debugger, why not look at the code and do a quick code
 review, using available evidence from the program crash or problem? 
 Often, the evidence plus looking at the code pinpoints the problem
 faster than the time it takes to start the program in the debugger.
   <blockquote><table bgcolor="#E0E0E0" border=1 cellpadding=2 cellspacing=0><tr><td>
   Use a debugger only as a last resort.  Having to resort to a debugger
   means your programming methodologies have failed.
   </tr></td></table></blockquote>
By now you are probably wondering how often I use the debugger in my
 programming environment.  Because of all the programming
 methodologies that I have in my bag of techniques, not very often.
 <br><br>
Your goal should be to develop and use programming techniques that
 catch your bugs for you.  Do not rely on a debugger to catch your
 bugs.


<br><a name="fixsymptom"><br></a>
<big><b>1.6 Fixing the Symptom and Not the Problem</b></big>
 <br><br>
Let's say you encounter a bug in your code.  How do you go about
 fixing the problem?  Before you answer, what is the problem?  Is the
 problem the bug itself, or is it what caused the bug to occur?
 <br><br>
All too often, the bug or symptom is being fixed and not the actual
 problem which caused the bug in the first place.  A simple test is
 to think how many times you have encountered essentially the same
 bug.  If never, then great, you are already fixing the problem and
 not the symptom.  Otherwise, give some careful thought to what you
 are fixing.  You probably want to come up with a new programming
 methodology that helps to fix the problem once and for all.
   <blockquote><table bgcolor="#E0E0E0" border=1 cellpadding=2 cellspacing=0><tr><td>
   When fixing a bug, fix the underlying problem or cause of the bug and
   not just the bug itself.
   </tr></td></table></blockquote>
A prime example is storage leaks.  A storage leak is defined as a
 memory object that is allocated but never freed by your program.  In
 most cases, the storage leak does not directly cause problems, but
 what if it happens on an object that gets allocated and (not) freed
 a lot?  You run out of memory at some point.
 <br><br>
Running out of memory is what caused you to start looking for the
 problem.  You eventually find the missing line of code that should
 have deallocated the memory object and add the memory deallocation
 into the program.  Bug fixed, right?
 <br><br>
Wrong!  The underlying problem of storage leaks going undetected is
 still in the program.  In fact, had the heap manager told you where
 there was a storage leak in your program, you would not have wasted
 your time tracking down the storage leak.  To fix the problem once
 and for all, the heap manager must tell you that there is a storage
 leak.  This programming methodology is discussed in
 <a href="chapter5.html">Chapter 5</a>.


<br><a name="unmaintainable"><br></a>
<big><b>1.7 Unmaintainable Code</b></big>
 <br><br>
We all have had the experience of modifying code that someone else
 has written, either to add a new feature or to fix a problem in a
 module.  I don't know about you, but for me it is typically not an
 enjoyable experience because the code is often so hard to understand
 that I end up spending the majority of my time just figuring out
 what is going on.
   <blockquote><table bgcolor="#E0E0E0" border=1 cellpadding=2 cellspacing=0><tr><td>
   Strive to write code that is understandable by other programmers.
   </tr></td></table></blockquote>
Good code runs.  Great code runs and is also easily maintainable.  In
 your code reviews, you should look for code that not only works, but
 also for code that is straightforward in how it works.  What good is
 a coding technique if it cannot be understood?  Consider the
 following.
 <br><br>
  <table bgcolor="#CCCCEE" cellpadding=0 cellspacing=0><tr><td><pre>
<b>Hard to understand code?</b>
nY = (nTotal-1)/nX + 1;
</pre></tr></td></table>
<br>
Is this code fragment hard for you to understand?  If not, then you
 know the technique being used.  If you do not know the technique,
 then it is sure frustrating to figure out.  This code is one way to
 implement the ceil function on the <tt>nTotal/nX</tt> value.
 <br><br>
Properly commenting your code is a good first step.  However, keep in
 the back of your mind that someone else is reading your code and
 avoid obscure programming techniques unless they are fully commented
 and documented in the project.


<br><a name="debugkernel"><br></a>
<table bgcolor="#F0F0F0"><tr><td>
<img src="images/windows.gif"> <big><b>1.8 Not Using the Windows Debug Kernel</b></big>
 <br><br>
I am primarily a Microsoft Windows developer and it astounds me the
 number of times I have run commercial Windows applications on my
 machine only to have them bomb because the Windows debug kernel is
 reporting a programming error such as an invalid handle.  The error
 is in such an obvious place that you know the developers did not use
 the debugging kernel of Windows during their development.  Why would
 anyone develop an application and not use the debugging kernel of
 the underlying environment?  It catches errors in your code
 automatically.
 <br><br>
The Windows development environment allows for running either the
 retail kernel or the debugging kernel.  The retail kernel is the
 kernel as it is shipped to the customer.  The debugging kernel has
 extra error checking not present in the retail kernel.  Error
 messages from the kernel may then be redirected to a secondary
 monochrome screen attached to the system.  This redirection is an
 option in the DBWIN.EXE program provided with Microsoft C8.  You
 should run with the debugging kernel all the time.
   <blockquote><table bgcolor="#E0E0E0" border=1 cellpadding=2 cellspacing=0><tr><td>
   Use the debugging kernel of your development environment.
   </tr></td></table></blockquote>
The Windows SDK provides D2N.BAT (debug to non-debug) and N2D.BAT
 (non-debug to debug) batch files in the BIN directory to switch
 between debug and non-debug Windows.  It is easy to accidentally
 leave your version of Windows in the non-debug mode.  It has
 happened to me a couple of times.  To detect this situation, I
 finally printed a special symbol in my application's status line to
 signify that it is being run under debug Windows.  I suggest that
 you do something similar in a place that is easy to spot in your
 Windows application.  To detect if you are running under debug
 Windows, use the GetSystemMetrics(SM_DEBUG) call.  It returns zero
 under retail Windows and a non-zero value under debug Windows.
</td></tr></table>

<br><a name="summary"><br></a>
<big><b>1.9 Chapter Summary</b></big>
 <br><br>
<ul type="disc">
<li>The first step in writing bug-free code is to understand why bugs
 exist.  The second step is to take action.  That is what this book
 is all about.
<li>Programming methodologies that are developed to prevent and detect
 bugs must work equally well for both small and large programming
 projects.
<li>A technique that helps eliminate data structure declarations from
 include files needs to be found.  Doing so will allow programmers to
 come up to speed on an existing project much quicker.
<li>Global variables that are known to more than one source file should
 be avoided.  Global variables make it hard to maintain a project.
<li>Debuggers should be used only as a last
 resort.  Having to resort to a debugger means that your programming
 methodologies used to detect bugs have failed.
<li>When you fix a bug, make sure you are really fixing the underlying
 cause of the bug and not just the symptom of the bug.  Ask yourself
 how many times you have fixed the same type of bug.
<li>Strive to write code that is straightforward and easily
 understandable by others.  Avoid writing code that pulls a lot of
 tricks.
<li>Finally, make sure that you use the Windows debug kernel all the
 time.  It contains extra error checking that can automatically
 detect certain types of bugs that go undetected in the retail
 release of Windows.
</ul>


<br><br><hr><center><small>
Copyright &copy; 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>