Geometry Applet Programming Tips
This page offers some useful tips for getting started in programming. These suggestions will help you to develop good programming practices that will make your work easier and more rewarding. We'll expand on each of these statements below, but our suggestions boil down to these four:
- Plan your work.
- Use careful naming, good formatting, and descriptive comments to make your code understandable.
- Work incrementally.
- When debugging, work methodically to isolate the problem.
1. Plan your work.
Don't start writing code without a plan. Draw a sketch of how you want your finished diagram to look. Label it. Think how you will create each element of your diagram (refer to the Geometry Applet Programming Reference section for a complete listing of the available construction methods), then note each method on your diagram (e.g., "free point," "lineSlider," "perpendicular point," etc.). Include on your sketch any "invisible" elements that you may need as a foundation for a visible element. If your sketch gets too messy to read, don't be afraid to start with a fresh one. This is common practice in engineering: refining your design by iteration. Keep your previous sketch(es) so you can refer back to it (them).
When you have a sketch that you like, and you've figured out how to construct each element in it, you're almost ready to start programming. There's one more thing left to do, and that is to put the construction into a logical order. You could number the elements on your sketch, or you could make a separate list. Check to make sure that each element has all of its precursors defined before adding it to your list.
Now that your plan is finished, you're ready to start writing code. With practice, you'll find that with a good plan, the program almost writes itself. Our next tip covers things to keep in mind as you turn your plan into code.
2. Use logical naming, descriptive comments, and clear formatting to make your code understandable.
Use logical naming. Take a look at your sketch and make sure that each element is named with a logic that makes sense in relation both to the other elements in the diagram, and to the sequence in which you wish to your viewer to consider the elements. Also make sure that any "invisible" elements have names that fit into, but don't interfere with, your overall scheme. For example, recall that in the right angle diagram (if you're thinking, "No, actually I don't recall," see Getting Started with the Geometry Applet), the invisible point that defined the perpendicular line was named D', corresponding with the visible point D. If the points had been thoughtlessly named in order of creation, both the program code and the resulting diagram would be harder to understand.
Use descriptive comments. Comments are "extra" lines that you put into the program to describe what you're doing at this particular point. They are specially marked so that they are ignored by the applet. Think of them as notes to yourself (or to someone else reading your program), explaining the logic of the program. For example, if you had a hard time figuring out some part of your construction, be sure to comment your eventual solution so that you can remember how you did it. You don't need to add a comment every line of the program, just often enough so that the flow of the program is clear.
Use clear formatting. Solid blocks of text are hard to read. If the code for your diagram is longer than about 10 lines, you may want to add blank lines at strategic points to set off related parts of the diagram. With the Geometry Applet, each line of code has the same basic structure. Aligning the "PARAM=" and "VALUE=" statements on each line will help you to scan quickly down columns to identify typographical errors such as missing quotation marks or the like.
3. Work incrementally.
When you are creating a program, it is almost inevitable that along the way you will also create bugs. Bugs are mistakes in your code that either cause your program to behave in ways that you did not intend, or cause it to stop working at all. The more lines of code, the more chances for bugs. So, especially when you are first starting, it is important to work incrementally. Make just one change at a time, make sure that it works as expected and then move on. With the Geometry applet, this is easy to do. To check your code, all you need to do is use your web browser to open the file containing your applet code. After you've made a change in the code with your text editor, just save the file, then switch to your browser and hit the re-load page button to see the change in action.
Also, it's a good idea to back-up your file once in awhile with a different name. That way, if something goes really wrong and you can't figure it out, you don't need to start over from scratch. Instead you can go back to an earlier version that worked, and start over from there.
As you gain more experience with a particular programming environment, you'll be able to write larger chunks of code at one time. Even then, it is important to remember to test each new section of code to make sure that it works as expected before moving on to the next piece. By getting in the habit of working incrementally, you'll reduce the amount of time you spend identifying and fixing bugs.
4. When debugging, work methodically to isolate the problem.
We told you above that bugs are inevitable, so how do you troubleshoot them? Well, the first step is to isolate the problem: which line caused the program to stop working as expected? If you are following tip 3 and working incrementally, you can be pretty sure that the problem is with the line you just wrote.
Check for simple typos first. The code for the Geometry Applet is in a rigid format, so typographical errors can easily cause "syntax errors." In other words, the applet doesn't understand what you're trying to say. For example, if the "PARAM=" and "VALUE=" portions of the new code don't line up properly with the preceding line, you've probably made a mistake typing (i.e. missing a character or added an extra character somewhere). Another simple mistake is leaving out the semicolon that separates the arguments in the "VALUE=" string for an element. Alternatively, you may have mistakenly used a semicolon instead of a comma when writing a list of parameters for an argument. Did you spell everything correctly? Did you repeat an element number, or skip one? Check your code carefully for these kinds of typing mistakes.
Next, double-check the Geometry Applet Programming Reference section and make sure that you are using the construction method properly. Make sure that the element types of your arguments match those specified in the documentation. Make sure that they are in the proper order.
It is possible that the bug occurred earlier in the program, but, until now, it was harmless. For example, maybe your newly-added element is the first one that depends on an earlier, invisible element which was improperly specified and not noticed until now. If you are sure that there is nothing wrong with the newly-added line of code, check to see what its dependencies are (what other elements are used in its construction?), and look for problems with them. If it depends on invisible elements, make them visible temporarily to assure yourself they're working properly.
Often, the broken diagram will give you a clue as to what is going on. For example, if you skip an element number, the applet will stop reading in elements with the one just prior to the break in sequence. The remaining elements are ignored. This can clue you in to look for a problem just after the definition for the latest element that appears properly. A related example is repeating an element. If you have two lines that begin with "PARAM NAME=e", for example, the second definition for e overwrites the first one. If you're not looking carefully, you'll see that both elements are defined in your code, but you'll miss the repeated numbering and wonder why one of them is missing.
Another possibility is that a construction method is not working quite as you had expected it to. Re-read the documentation. Use the u key to "lift" your diagram into a new browser window and maximize it, then drag your diagram around to see if one of your points is unexpectedly showing up somewhere outside the normal boundaries of the figure.
If all else fails, go back to a previously saved version of your diagram and start over. You may even need to re-think your construction method (but this should happen rarely if your initial plan was carefully made).
You might also want to take a look at our Engineering & Programming Project Tips for useful tips on your whole project.
The next page uses these programming tips to walk through the construction of a more challenging diagram: Coding Your Own Diagram: Example 2.