Debugging and Android Setup

Today’s lab begins teaching you to debug and starts preparing you to work on this semester’s Android-based machine project. You’ll start by completing some in-lab homework problems that help you learn to debug problems with your code. Next you’ll start preparing your Android development environment—although we expect you to return to office hours this week to complete this task.

1. Learning How to Debug (40 Minutes Total)

Programmers never stop making mistakes. I’ve been doing this for 20 years 1 and I make many, many programming mistakes every day. What you do get better at is fixing them, quickly, so that they don’t slow you down and you can get on with your business of changing the world.

Our first lab homework assignment today is designed to help you learn to do that. This knowledge will come in handy in all of your future programming tasks—but definitely during your CS 125 CBTF quizzes this semester, where you may small mistakes and be pressed for time.

Oh, and in case you’re wondering, programmers have long referred to fixing mistakes in their code as debugging, a term attributed at least in part to computer science pioneer Grace Hopper 2.

1.1. Understanding Your Program’s Output (10 Minutes)

A key part of learning to debug effectively is understanding the various kinds of output that your program produces. You can just stare at your code and try to figure out what’s wrong—that might work, eventually, maybe. But it’s slow. Frequently a much faster route is to use the output that the computer provides when testing your code to help you fix it.

Note that this is not just an artifact of how we do things in CS 125. Every large tech company has sophisticated systems for testing their code before it is released to users or to the public. This is because mistakes can be both embarrassing and expensive, so it’s better to test things first rather than try to clean up the mess later. Before modifications get made to widely-used pieces of software like, say, the Chrome browser, those changes go through extensive automated testing along with multiple rounds of review by other human developers. So increasingly one of the many things that computers are helping automate is the process of testing changes to their own code!

When you submit your program for grading in CS 125 the following steps take place.

1.1.1. Code Format Checking

First, we test the format of your code using checkstyle, a program that checks it against a set of rules about how Java code should be formatted. We do this because writing readable code is as important as writing correct code.

For example, the following code has a checkstyle error—can you spot what it is?

if (x>0) {
  System.out.println("x is positive");

checkstyle produces error messages that look like this (note that this is not for the snippet above):

[ERROR] /base/src/main/java/ 'else' is not preceded with whitespace.
[ERROR] /base/src/main/java/ '}' is not followed by whitespace.

Note that the error message identifies the line number (3) where the error occurs, along with a brief human-readable description of the problem. Given the error message above, can you come up with a snippet that could have produced this error?

1.1.2. Compilation

Second, we try to compile your code using the Java compiler. This is step that we’ll discuss more soon in class, but certain kinds of mistakes can be caught at this point. We sometimes refer to errors identified at this stage as compiler errors or syntax errors. Note that if the Java compiler can’t compile your code we can’t run it and continue with testing, so we stop at this point.

For example, the following code will produce a compiler error—can you spot it?

double latitude = 80.98274;
if (latitute > 0) {
  System.out.println("You're in the northern hemisphere");

The Java compiler can produce all kinds of error messages depending on what you did wrong. Understanding how to interpret them will greatly improve your ability to fix errors and perform well on the homework, quizzes, and MPs. Here are a few examples of common mistakes. Note that, like the checkstyle errors above, each identifies the line number where the error took place and provide some information about the problem that was encountered. For each, see if you can determine a piece of code that could produce that error.

/base/src/main/java/ error: cannot find symbol
        if (currenttime > 10000000) {
  symbol:   variable currenttime
  location: class Question
1 error
/base/src/main/java/ error: reached end of file while parsing
1 error
/base/src/main/java/ error: ';' expected
1 error

1.1.3. Testing

Finally, we run your code using a test suite. At that point your program will run, but it might not be correct. For example, we may have asked you to add x and y but if your code instead computes x * y, then it doesn’t match our specification. Our test suite will try and determine this and, if your code doesn’t behave correctly, we’ll provide some information about what went wrong.

Usually how we do this is to compare the behavior of your program to what we had expected. For example, let’s say that we instructed you to write a snippet of code that printed North Pole at the appropriate latitude and longitude and not print anything otherwise. You submitted the following code:

if (latitude == 0.0) {
  System.out.println("North Pole");
} else {
  System.out.println("Not at North Pole");

What we would do is test your code with different values of latitude. First we’d say, let’s see if it’s right if latitude is equal to 0.0. In that case it does print North Pole, so that’s good. OK, now what happens if we set latitude to 1.0? We didn’t tell you to not print anything otherwise, but you printed Not at North Pole. So you might get an error message something like this:

java.lang.AssertionError: expected [] but found [North Pole]

These error messages might look different depending on the problem you are working on. But in general they describe a mismatch between our expectations of how your code should behave based on our instructions and the reality of how it worked when we ran it.

1.2. Practice Debugging (30 Minutes)

Next, you should use the next 30 minutes on our in-lab homework. You will only be able to access this homework beginning 10 minutes after your lab starts and ending 30 minutes later. So if your lab starts at 9AM, you can start the homework at 9:10AM and should complete it by 9:40AM. And if you are in the wrong lab you will not be able to complete the lab homework assignment—please attend the right lab next time.

Please feel free to work with a partner or in a small group on the lab homework. But every student must submit their own answers to receive credit.

Note that the best way to approach these debugging problems is not to just resubmit your solution over and over again. In fact, we’ve disable cut and paste on these problems to prevent you from doing that. Instead, first run the code, then use the output to identify the errors, and then fix them by modifying the code that is in front of you. All of these errors can be fixed with only a few keystrokes.

2. Installing and Using Android Studio (Remaining Time)

Next, begin working through our Android Studio setup tutorial. Ask for help if you get stuck—installing complicated software can be tricky.

To work on our CS 125 MPs, you will need either an Android device or a working emulator—even if it runs a bit slowly. Again, work with the course staff to try and complete this portion of the lab, and plan on returning during office hours later this week.

Note that if you have an Android device you should use it for Android development. Even an old and slow Android device can provide a more enjoyable development environment than using the emulator on a powerful laptop.

3. Before You Leave

Don’t leave lab until:

  1. You’ve reviewed our debugging instructions and completed our first in-lab homework.

  2. You’ve started installing and learning to use Android Studio. Again, we do not expect you to finish this in lab. Schedule some time to come to office hours this week to complete this task. Or post on the forum and we’ll be happy to help.

CS 125 is now CS 124

This site is no longer maintained, may contain incorrect information, and may not function properly.

Created 10/24/2021
Updated 10/24/2021
Commit a44ff35 // History // View
Built 10/24/2021 @ 21:29 EDT