| CPSC 124 | Introduction to Programming | Spring 2024 |
Last week's lab introduced the programming environment and the cycle of editing, compiling, and running Java programs. This week's lab contains some additional configuration of the VS Code environment, introduces some common compiler error messages and how to solve them, and gives you a chance to create some programs using the things covered in class and the reading:
Make sure you have read and understand how academic integrity applies in this course (and specifically how it applies to labs).
All of the marked steps in the Setup section must be done by each person individually. It's fine to give and receive help, and even to go through the steps collaboratively with someone else, but you still need to carry them out for yourself (and understand how to carry them out).
For the exercises, the usual collaboration rules apply:
Labs and projects are for practice and learning. While it can be very productive to work on problems with your peers, it is also easy to underestimate how much you yourself understand and can do in such situations - so often something looks easy when someone else does it! With this in mind, you should always make the first attempt on a problem or programming task yourself using only the resources provided for the course (textbook, slides and examples posted on the schedule page, other resources linked on the course webpages). After that point, you are encouraged to come to office hours and/or go to Teaching Fellows. You may not collaboratively write solutions or code, and you may not copy solutions or code written by others, even if you contributed ideas.
You can discuss specific exercises with other students in general terms - such as how you might get started on that problem, or how or when to use various programming constructs, or strategies for debugging - but how to use a particular programming construct to solve a specific problem or debugging a particular program should only be discussed in office hours or with the Teaching Fellows.
There are some additional settings that are important or useful in VS Code. This configuration only needs to be done once, unless you want to later change the setting.
To access the VS Code User configuration settings:
You should see something similar to the picture below. (Make sure that "User" (upper left corner) is highlighted/underlined instead of "Workspace".) The (many) configuration options are organized into a hierarchy of categories which can be accessed through the list on the left (under "Commonly Used" in the picture). Click on the > icon next to a category label to expand that category and see the subcategories within it.
In the following, "Navigate to A → B → C" means to open category A to find category B within it, then open category B to find category C within it, then click on category C to see the settings within category C.
Configure an aspect of the Java language support extension that you installed in lab 1:
Turn off the extension recommendations that pop up periodically:
The rest of the settings below are personal choices - they are recommended and you are encouraged to try them, but you can decide for yourself whether to keep the setting or turn it off again.
Turn on autosave so that your files are saved more or less as you type: (which helps avoid the "forgot to save before compiling" problem)
Have the autoformatter invoked automatically in certain situations: (so you can get the benefit of easier-to-read code and are more likely to quickly notice problems like a missing semicolor or curly bracket)
To prepare for this lab:
The files copied will be used in some of the exercises below.
Compiler errors occur when you make a mistake in the syntax of the program - if the syntax is not exactly correct, the compiler can't translate the program into Java bytecode so that it can be run. Training yourself to pay attention to the details of syntax is something you'll need to do as you develop your programming skills, but even experienced programmers still make syntax mistakes. Thus, it is important to understand the error messages the compiler generates so you can easily fix them.
In this exercise, you'll deliberately make certain kinds of errors to see what the error messages look like. To get started:
In VS Code:
Now, for each of the following tasks, make the change described, save the file, and compile it. In your errors.txt file, record the exact text of error message that is generated, and summarize (in your own words) what the error message means. Some notes:
Change the very first line of ErrorMessages.java so that it reads
public class errormessages {
and then save and compile ErrorMessages.java.
Next, change the first line to
public class ErrorMsgs {
and save and compile.
What error messages do you get? What's the problem?
Fix the error before continuing to the next step - i.e. change the line back to what it was originally. (Recompile once you've fixed the error to make sure it was fixed correctly.)
Find the line
int number;and comment it out, that is, change it to look like the following:
// int number;
Save and compile. What's the error message? What's the problem? Remember that the compiler ignores anything in a comment, so commenting out a line like this has the same effect as deleting the line entirely - but has the advantage that it is easy to restore the line later by removing the //.
Fix the error before continuing to the next step - remove the comment symbols. (Recompile once you've fixed the error to make sure it was fixed correctly.)
Change the declaration of number so that it looks like this:
int Number;(That's a capital N.) Save and compile. What's the error message? What's the problem? Fix the error before continuing to the next step - restore the original line. (Recompile once you've fixed the error to make sure it was fixed correctly.)
Add a second declaration for number after the first, so it looks like this:
int number;
double number;
Save and compile. What's the error message? What's the problem?
Fix the error before continuing to the next step - remove the second line.
(Recompile once you've fixed the
error to make sure it was fixed correctly.)
Change the declaration of number so that it looks like this:
String number;Save and compile. What's the error message? What's the problem? Fix the error before continuing to the next step - restore the original line. (Recompile once you've fixed the error to make sure it was fixed correctly.)
Remove the semicolon from the end of the first System.out.print statement:
System.out.print("enter a number: ")
Save and compile. What's the error message? What's the problem?
Note: sometimes one error will confuse the compiler and lead to a bunch of messages, some of which might not actually be problems. As a result, it is good idea to fix the errors one at a time starting from the first error message listed. After each fix, save and recompile the program.
A second note: sometimes one error will confuse the compiler so much that it won't report additional errors - but when you fix the first error, the next compile attempt will produce more errors. Don't take this to mean that your fix was incorrect! If the particular message that you were trying to fix has gone away, you probably fixed it correctly.
Your program should convert miles into three other measures of length: kilometers, rods (historically used for surveying land), and nautical miles (used at sea). The number of miles should be read as input from the user. When you are done, your program should behave as shown: (including formatting - make sure you have line breaks, spaces, and blank lines exactly as shown)
Enter a length in miles: 3.6 3.6 miles is 5.793649987299975 kilometers 1152.0 rods 3.128320727483788 nautical miles
What the user types in is shown in bold underline to distinguish it from what your program should output.
The conversions:
For extra credit, use formatted output to limit the numbers printed to two decimal places. In the example above, this would mean printing "5.79 kilometers", "1152.00 rods", and "3.13 nautical miles".
Write a program called Conversation to carry on a short conversation with the user as described below. Utilize incremental development and employ good programming style.
Your program should ask the user for some information and should use that information in its responses. Here a sample conversation, with what the user types in as the program runs shown with bold underline to distinguish it from your program's output:
Hi, my name is HAL. What's your name?
Dave
Hi Dave. Nice to meet you.
How many years old are you, Dave?
21
Wow, 21! You must have been born in 1989.
What's that in your hand, Dave?
.
.
.
Your program is essentially a script for the conversation. You are welcome to be as serious or absurd as you want to be.
You should have at least five questions and answers, which means you will need (at least) five variables to hold the user's input. At least one user answer should be used in more than one of the computer's responses (like the name "Dave" is in the sample). The program should ask for at least one number, and it should do some calculation with that number (the sample uses the age to compute the year in which the user was born). You should also use at least one subroutine from the Math class (section 2.3.1 of the textbook) and one subroutine from the String class (section 2.3.3 of the textbook). "Using a subroutine" means writing a subroutine call - a computation like 3*5 is doing a mathematical operation, but it's not a subroutine from the Math class.
Don't forget to hand in your work when you are done!
Grading in labs will be based on two things: functionality and style. The largest component of the grade is functionality - whether your program does what the exercise asks. Details may be important here - for example, if the exercise specifies certain formatting, your program's output must have exactly the same formatting in order to earn full credit. (At other times, particular elements may not be specified exactly in the exercise and then you are free to pick something appropriate.) The other component of the grade is style which, as outlined here, includes following naming and indentation conventions, using whitespace to improve readability (including avoiding overly long lines), and appropriate commenting.