|
Tracing Progams |
One of the long-term goals of this class is for you to be able to write programs, correctly, without needing anything other than what you've got in your head. In order to be able to write programs correctly, you need to be able to correctly predict what a given program will do. In essence, you want to be able to simulate what the robot will do, in your head, without ever having to run the program on an actual computer.
The nice thing about computers is that they've very predictable, and very methodical. Given the same starting point, and the same set of instructions, the computer will do the exact same thing every single time that the program is run. Therefore, you need to learn how to be methodical and predictable, much like a computer is. Once you've done this, you can write a program, mentally simulate it, and if it's wrong, fix it without ever having to run the program. This is much faster than typing something into the program, hoping it works, running the program, guessing why it doesn't work, and repeating the whole thing till you get the hang of it.
The technique that we'll use here is called code tracing. We're going to use a format very similar to the one used in the book. Remember to fill out a single line in the table below for EVERY line between the start and end of main in the sample code. The table is stored on the class website, under Course Info / Blank Documents, behind the link named Program Trace Table.
Once you've traced out the code in excruciating detail, make sure that you can go back, and "mentally trace through" the program again, keeping track (in your head) as much as possible what the program is doing – where the Robot, Things, and Walls are, etc,etc.
You should use the table to trace the code located on the website, behind the link labeled ICE_02_02_Trace.java.
(Note that you have to do this on your homework assignment, so it's a good idea to practice here in class)
We can express what the programs in Java source code if we want, but this is a time-consuming and exacting language – it's often difficult to clearly say what it is that the program does just from looking at the code. So we want to look for other ways to tell our fellow programmers what the program is supposed to do. One way we can do this is by commenting our code.
A comment is a region of code that the Java compiler ignores. That means that we can put whatever we want there, knowing that it's not really part of the program anyways. In particular, we can put an description, in English, of what we intend for our code to do, in order to make it clear what the program is supposed to do. This is often a good way to find logical (intent) errors – the comment says that the program should do one thing, but the actually does something else.
There are a number of different ways you can comment your code in Java. We'll start with a single line comment. Somewhere on the line, you should put two forward slashes right next to each other. If you do this right, jGrasp will color-code them orange, like so:
//
Anything that you write AFTER the slashes is ignored, so you can put English there, and everything will work fine. You should use this to clarify what your code is about to do:
// Make Jo turn right by turning left 3 times
Jo.turnLeft();
Jo.turnLeft();
Jo.turnLeft();
As an aside, anything on the line BEFORE the slashes is normal Java code:
// Make Jo turn right by turning left 3 times
Jo.turnLeft();
// First turn -
90 degrees
Jo.turnLeft();
// Second turn -
180 degrees
Jo.turnLeft();
// Last turn -
270 degrees
// same as 90
deg turn to right
You should make sure that you can do this in your own time, because you're required to document the code you hand in for homework assignments.
ICE #9: Flowcharts: Moving Around In A City (Optional)
As you've seen in class, flowcharts can be a very useful way of representing what a program is doing. For example, I could flowchart a generic city-creation procedure using the flowchart in Figure 1, located at the end of this document. The flowchart is the linked boxes down the left-hand side; the stuff on the right is just annotations to help you understand what the flowchart is trying to say. Note that you have to create the City first. You can create Robots, Things, and Walls in any order you like, creating as many (or as few) of each as you want.
You won't be expected to create flowcharts on your own, but you will be expected to read them, and be able to translate them into Java code.
One of the most useful attributes of a flowchart is that it can tell you what a program should do, so that you can write a program from the flowchart. Download the file stored in the file Flowchart.java, and then add code to the file so that the robot does what the following flowchart says it should:
Figure 5: Another Flowchart
You should be able to create Java code that will actually make the robot do everything the flowchart specifies, including finding any compile-time errors that may arise. You should also be able to trace your code, in order to verify that the robot does everything correctly, thus helping you find any intent (logical) errors that you've inadvertently introduced. Lastly, you should be able to run your program, and watch it do the correct thing.
For this ICE, you're only required to write the code, but you should probably spend out-of-class time, on your own, making sure that you can do everything else, as well.
(This exercise should bring together everything we've done today, and with careful reasoning, you could probably justify meeting any outcome. You should reflect upon what you've done, what you've learned, and pick an appropriate outcome to write about.)
Figure 6: Flowchart Explain How To Create A City