Adriatico's Blog

You will need a few tools for your work. I have provided them on the CD that comes with this book. Please resist any temptation to use tools from elsewhere. They will be excellent when you have gained confidence and fluency with programming. However, their complexity will overwhelm you while you are struggling to learn to program. It is enough to try to do something new without also trying to do it in an unnecessarily complicated environment.
You also need something to manage these tools with rather than having to remember every detail for yourself. Programmers use things called IDEs (Integrated Development Environments), which are rather like carpenters’ workbenches. Those that come with commercial compilers, or even the free ones that are used by experienced programmers, have a multitude of options that will simply get in your way and lead to confusion. (No differences here, then; professional work environments are rarely suited to the newcomer.)
So I have chosen a very simple IDE written and maintained by Al Stevens. He calls it Quincy and it provides just what we want: enough to work with but no frills to get in the way. If you have followed the instructions for installing the software you will have installed Quincy somewhere on your system (perhaps on the C drive, but possibly somewhere else; I have my copy on my E drive). You should have an icon of a cat’s face on your desktop. Click (or double-click, depending on how your system is set up) on it to open Quincy.

There are some things that you need to do every time you prepare to write a new program. I am going to walk you through them this time with images from my screen to help you. Until you get used to it, come back to this section each time you start a new program and follow through these steps.

• Create a new project Select ‘‘Project’’ by double-clicking on it (or click and select ‘‘OK’’). Type ‘‘my first program’’ (get into the habit of giving descriptive names to projects and other files) in the Target name box. Use the browse button to find the sub-directory. You should find that in the directory called ‘‘tutorial’’ on the drive where you installed the tools from the CD. When you have found it, left click the OK button in the browse dialog box. Check that the ‘‘Type of Build’’ selected is ‘‘Console application’’.
• Set the project options Select the ‘‘tools’’ menu and choose options. You should see the image at the top of the next page. Make sure that the boxes have been selected as in this image. Then use the browse button beside the Includes box to find the sub-directory called ‘‘fgw headers’’. That should be one of the other sub-directories in the same place. Click OK in the browse dialog and then click OK in the Options dialog box.
• Get the special libraries Much of the programming you will be doing relies on two special files. Do not worry about exactly what they are; they contain resources that one of the programming tools will need. You have to find these two files and include them in the project. Click on the Project menu and select ‘‘Insert Files’’. You should then use the drop down menu in the dialog box to find the fgw headers sub-directory. You should then see something like this (the exact file list may be different, but the two important files fgwlib.a and libgdi32.a should be there. (If they are not in the sub-directory, your installation from the CD is faulty. Copy the contents of the fgw headers directory on the CD to tutorial\fgw headers.)
• Save the project Go to the File menu in Quincy and save the project.

Minimize the scope of local variables

“Minimize the accessibility of classes and members.” By minimizing the scope of local variables, you increase the readability and maintainability of your code and reduce the likelihood of error. The C programming language mandates that local variables must be declared at the head of a block, and programmers continue to do this out of habit; it’s a habit worth breaking. As a reminder, the Java programming language lets you declare variables anywhere a statement is legal.

The most powerful technique for minimizing the scope of a local variable is to declare it where it is first used. If a variable is declared before it is used, it is just clutter—one more thing to distract the reader who is trying to figure out what the program does. By the time the variable is used, the reader might not remember the variable’s type or initial value. If the program evolves and the variable is no longer used, it is easy to forget to remove the declaration if it’s far removed from the point of first use. Not only can declaring a local variable prematurely cause its scope to extend too early, but also too late. The scope of a local variable extends from the point of its declaration to the end of the enclosing block. If a variable is declared outside of the block in which it is used, it remains visible after the program exits that block. If a variable is used accidentally before or after its region of intended use, the consequences can be disastrous.

Nearly every local variable declaration should contain an initializer. If you don’t yet have enough information to initialize a variable sensibly, you should postpone the declaration until you do. One exception to this rule concerns try-catch statements. If a variable is initialized by a method that throws a checked exception, it must be initialized inside a try block. If the value must be used outside of the try block, then it must be declared before the try
block, where it cannot yet be “sensibly initialized.”
Loops present a special opportunity to minimize the scope of variables. The for loop allows you to declare loop variables, limiting their scope to the exact region where they’re needed. (This region consists of the body of the loop as well as the initialization, test, and update preceding the body.) Therefore prefer for loops to while loops, assuming the contents of the loop variable(s) aren’t needed after the loop terminates.

The second loop contains a cut-and-paste error: It initializes a new loop variable, i2, but uses the old one, i, which unfortunately is still in scope. The resulting code compiles without error and runs without throwing an exception, but it does the wrong thing. Instead of iterating over c2, the second loop terminates immediately, giving the false impression that c2 is empty. Because the program errs silently, the error can remain undetected for a long time.
If the analogous cut-and-paste error were made in conjunction with the preferred for loop idiom, the resulting code wouldn’t even compile.

Moreover, if you use the for loop idiom, it’s much less likely that you’ll make the cut-andpaste error, as there’s no incentive to use a different variable name in the two loops. The loops are completely independent, so there’s no harm in reusing the loop variable name. In fact, it’s stylish to do so.
The for loop idiom has one other advantage over the while loop idiom, albeit a minor one. The for loop idiom is one line shorter, which helps the containing method fit in a fixed-size editor window, enhancing readability.

This idiom is useful for random access List implementations such as ArrayList and Vector because it is likely to run faster than the “preferred idiom” above for such lists. The important thing to notice about this idiom is that it has two loop variables, i and n, both of which have exactly the right scope. The use of the second variable is essential to the performance of the idiom. Without it, the loop would have to call the size method once per iteration, which would negate the performance advantage of the idiom. Using this idiom is acceptable when you’re sure the list really does provide random access; otherwise, it displays quadratic performance.

Again, this idiom uses two loop variables, and the second variable, n, is used to avoid the cost of performing redundant computation on every iteration. As a rule, you should use this idiom if the loop test involves a method invocation and the method invocation is guaranteed to return the same result on each iteration.
A final technique to minimize the scope of local variables is to keep methods small and focused. If you combine two activities in the same method, local variables relevant to one activity may be in the scope of the code performing the other activity. To prevent this from happening, simply separate the method into two: one for each activity.