Chapter 29: Ten Ways to Solve Your Own Programming Problems 355

Simplify

Avoid the temptation to gang up several commands on one line until you’re certain that that part of your code works well. Do this for many reasons, but most importantly because it makes your code more readable. The more read­ able your code is, the easier it is for folks (including you) to find an error.

For example, rather than write this line:

while(toupper(getch())!=ZED)

write this one:

while( ch != ZED)

{

ch = getch();

ch = toupper(ch); /* and so on */

Yeah, it may take a few more lines, but if you get an error in one of those lines, you know exactly where to look. Before then, you could have had several potential trouble spots.

Also, the second example is more readable to other programmers.

Finally, when you’re certain that your code works, you can compact things on one line — if you want to. Remember that the object is to get the program to work, not to try to impress other programmers with your source code.

Talk through the Program

One of the best ways to find bugs almost instantly is to show your code to another programmer. But that other programmer isn’t familiar with what you’re doing. What you do is start “talking through” the logic of your code. You explain what does what and why you made the choices you did.

Suddenly, as you’re explaining what you did, you discover that one spot in your code that doesn’t match your intentions. You say, “A-ha!” The other programmer nods in agreement, and you’re on with your work.

This technique of talking through your program works whether or not another programmer is present.

356 Part V: The Part of Tens

Set Breakpoints

You know that the bug is in the windshield() function, but you don’t know where. Does the bug lurk at the beginning of your code? In the initialization routines? Just before the big math functions? Near the end? Where? Where? Where?

One way to find out is to put breakpoints into your program. At a certain spot, stick in a return() or exit() function, which immediately stops the program. That way, you can narrow down the pesky code. If the program stops per the breakpoint, the fault lies beyond that point in the program. If the program doesn’t stop with the breakpoint, the fault lies before it.

Monitor Your Variables

Sometimes, a program runs amok because the values that you suspected were in your variables just aren’t there. To confirm that the variables aren’t carrying something outrageous, occasionally toss in a printf() statement to display their values to the screen. Never mind if this technique screws up the display; the purpose is debugging.

For example, I had a program with a nasty endless loop in it. I couldn’t figure out for the life of me why it repeated and repeated. Talking through the source code did nothing. But after I stuck in a printf() statement that displayed the looping variable’s value, I noticed that it merrily skipped over the end-of- loop value and kept incrementing itself to infinity and beyond. I added a simple if statement to fix the problem, and the program ran just fine afterward.

Document Your Work

At university, they’re on you like gum on a theater floor about comments. Comment this! Comment that! I remember seeing classmates turn in projects that were three pages of greenbar paper in length, and half of that consisted of the dumb comments at the “top” of the program. Such nonsense impresses no one.

True, document your work. But documentation merely consists of notes to a future version of yourself. It’s a reminder to say “This is what I was thinking” or “Here is where my train of thought is going.”

You don’t have to document every little stupid part of the program. This comment is useless:

			Chapter 29: Ten Ways to Solve Your Own Programming Problems 357
	i++;		/* add one to the value of i */

Here’s a better comment:

/* Remember that zero is the first item, so increment variable i here to account for that and not confuse the user. */

i++;

Comments can also tell a future version of yourself where to start working on the program if you come back to it later:

/* This is the payoff routine. In the future, it would be cool to add a sound effect here, say, coins in a hopper a la a slot machine. */

Comments can also be notes on what to fix, to remind you of what went wrong before and to give you tips on how to approach the problem:

/* I can’t get the dumb address to resolve here. The routine is supposed to work, but it keeps returning

a null value. Appendix C of the Davis book contains the original routine. */

Use Debugging Tools

If your compiler features a debugger, use it! Debuggers let you surgically view your program as it runs, monitoring variables and examining how the com­ puter literally steps through the code.

The problem with debuggers is that you usually need to compile a special version of the program, after it contains the debugging code. This makes the program huge and sluggish. If you use a debugger, remember to not use the debugger code when you compile your final program.

Use a C Optimizer

Many fun tools out there examine your code and make suggestions for opti­ mization. One common tool is lint. Other tools exist as well; any C program­ ming Web site lists the variety — and many of them are open source (thank you, open source community).

358 Part V: The Part of Tens

Just as a spell checker doesn’t make you a better writer, optimizers don’t make you a better programmer. But they can help hone your code so that it runs better.

Other programming tools are available as well. In fact, the whole Unix operating system is designed around programming. If you have time, consider looking into these tools: touch, make, and grep.

Read More Books!

One question I often get from programming acolytes via e-mail is “What book should I read next?” Well, obviously, the companion to this book, C All-in-One Desk Reference For Dummies, (Wiley) is an excellent choice. But the real answer is “Where do you want to go with your programming?”

If you want to program games, get books on game programming. You can find books for programming networks, programming the operating system, pro­ gramming graphics, and on and on. Some, you may have to find in university bookstores, but they exist.

As far as other programming languages are concerned, after reading through this book, you will know about 95 percent of the C++ program­ ming language. That would be a natural extension to this book. But also consider finding out how to use Perl, Java, Python, or any combination of those languages.

The PHP Web page creation language is also a good choice if you happen to be into the Web.

Above all, program. Practice. Devise new projects and work on ideas. Programming, to many folks, is like solving an enjoyable puzzle. Immerse yourself in it. Have fun!