Chapter 28: Ten Tips for the Budding Programmer 351
	Windows/DOS	Unix		What It Does
	cd	pwd		Displays the name of the current directory or folder.
				Use this command to ensure that you’re in the prog/
				c/learn directory.
	type	cat		Displays a text file’s contents on the screen; follow
				type or cat with the name of the file you want
				displayed:
				type source.c
				cat source.c
	del	rm		Deletes a file; follow del or rm with the name of the
				file to delete, as in del bye.c or rm bye.c.
	exit	exit		Closes the command-prompt window and closes the
				terminal.

Refer to a good book or reference about the command prompt for more details on these and other handy commands you can use while you program.

Carefully Name Your Variables

Though I use a lot of single-letter variable names in this book, be a better, wiser person when it comes to naming variables in your own programs. For example, x is an okay variable name, but counter is much better.

This may seem like a silly thing for a tiny program, but when your programs get larger, you may find that that a quick x or a variable you declared is being used by some other part of the program. Bad news!

Know Your Postand Pre-Incrementing

and Decrementing Riddles

The ++ and -- operators can certainly come in handy for incrementing or decrementing a variable’s value. But keep all your C language statements on a single line, and remember that ++ or -- before the variable name does its job before the variable’s value is used. If you put the ++ or -- after the variable name, the operation takes place afterward.

Refer to Chapter 25 to find out about this concept.

352 Part V: The Part of Tens

Breaking Out of a Loop

All your loops need an exit point. Whether that point is defined in the loop’s controlling statement or set inside the loop by using a break command, be sure that it’s there!

I recall many a time sitting at the computer and waiting for the program to “wake up,” only to realize that it was stuck in a loop I had programmed with no escape clause. This is especially easy to do when you work on larger pro­ grams with “tall” loops; after the source code for the loop extends past the height of your text editor, it’s easy to lose track of things.

Chapter 29

Ten Ways to Solve Your Own Programming Problems

In This Chapter

Work on one thing at a time

Break up your code

Simplify your job

Talk through problems

Set breakpoints

Monitor variables

Document

Use debugging tools

Use an optimizer

Read more books!

Welcome to the world of debugging. In my travels, I’ve met only one pro­ grammer who could sit and code a whole project from scratch and

have it compile and run the first time. As it turns out, he was able to do it only once — and it was a project he was well familiar with. Although he’s one of the world’s best programmers, the dream of writing, compiling, and running, all in that order, remains a dream for most programmers.

Yes, your programs error. You have typos that the compiler shouts out at you. But your programs also have bugs. That is, they compile and link just fine, but when they run, they do unexpected things. Well, all programs obey their orders. It just happens that the programmer may forget something now and then. It’s those times when you need to turn to this chapter and review my ten ways of solving your own programming problems. Do this before you phone, e-mail, or post your problem to the public. The public will thank you!

354 Part V: The Part of Tens

Work on One Thing at a Time

Address your bugs one at a time. Even if you’re aware that the program has several things wrong with it, fix them methodically.

For example: You notice that the title is too far to the right, random characters are at the bottom of the screen, and the scrolling technique doesn’t move the top row. Avoid the temptation to address all three issues in the same editing job. Instead, fix one problem. Compile and run to see how that works. Then fix the next problem.

The problem you run into when you try to fix too much at once is that you may introduce new errors. Catching those is easier if you remember that you were working on, for example, only Lines 173 and 174 of your source code.

Break Up Your Code

As your source code gets larger, consider breaking off portions into separate modules. I know that this topic isn’t covered in this book — and it probably isn’t a problem you will encounter soon — but separate modules can really make tracking bugs easy.

Even if you don’t use modules, consider using comments to help visually break up your code into separate sections. Even consider announcing the purpose of each section, such as

/********************************************* Verification function

---------------------

This function takes the filename passed to it and confirms that it’s a valid filename and

that a file with that name doesn’t already exist.

Returns TRUE/FALSE as defined in the header.

*********************************************/

I also put a break between functions, just to keep them visually separated:

/********************************************/