CS173: Intro to Computer Science - Using the Debugger (100 Points)
Assignment Goals
The goals of this assignment are:- To use the debugger to identify code bugs
Background Reading and References
Please refer to the following readings and examples offering templates to help get you started:The Assignment
In this lab, you will practice using the debugger to identify and fix a bug in a piece of code.
Part 1: Using the Debugger
Step 1: Download the Sample Project
Begin by downloading and opening this NetBeans project. Once you open the project, it may be necessary to close and re-open NetBeans to refresh the project files.
This code attempts to compute the slope of the line connecting two Cartesian points. Run the project. You’ll notice that the slope is 1, although this is incorrect.
Step 2: “Breaking” or Pausing the Program at a Certain Point
Set a Line Breakpoint at line 25 of the code, and start the debugger until it breaks at this line. Hint: you may wish to refer to our debugger tutorial for guidance on using the features of the debugger.
Step 3: Adding a “Watch” to Inspect Variable Values
When you run the debugger and it pauses (“breaks”) somewhere in the code. A pane appears at the bottom of the window indicating the variable types and values. Here, you can inspect the values of the variables in your program at this point in the execution. You can also add new watches. Click to add a new watch, and enter ydiff / xdiff as the watch expression. Note that you can even watch expressions, not just variables!
Step 4: Fix the Bug!
What is the value of this watch, and what is its type? Does its value make more sense given the context of its data type? What happened to cause this program to fail, and what can be done to fix it? Hint: you may wish to refer to our discussion of Data Types, Operators, and Expressions. Fix the data types of the xdiff and ydiff inputs so that they divide as floating point values, rather than as integers.
Make the needed repair, then stop and re-run the debugger. Check the watch expression ydiff / xdiff again and verify that it is working correctly.
If you would like to re-run the debugger from the beginning, you can stop the current debugging session (because it might think you are still paused at a breakpoint!) using the stop toolbar button at the top of your window, as shown below. Then, you can start the Debugger using the Debug menu like before!
You can submit this project as usual, by adding your README and exporting the project to a ZIP file for submission.
Part 2: Debugging to Find a Bug
Now, open this NetBeans project, and use the debugger to find and fix the error in the program!
Part 3: Bug Hunt
On the class activities discussion board, post at least two bugs that you’ve found in your own code. Let us know whether it was a syntax error (a typo that prevented your program from running) or a logic error (a program that ran but did something you didn’t expect). Let us know the error message you received, what the problem was, and how you fixed it. Each student that is the first to discover and report a unique bug will receive 3 points of extra credit on this lab, and up to 15 extra points total!
Submission
When you’re done, write a README for your project, and save all your files, before exporting your project to ZIP. In your README, answer any bolded questions presented on this page. Here is a video tutorial describing how to write a README for your project, and how to export it. You can submit multiple zip files, so feel free to export all your projects.
Trivia
The first computer “bug” is attributed to Grace Hopper, when an actual bug was found in the circuitry of a system, causing the program being executed to fail! Here’s a picture from their engineering journal.
Did you know that the most copied StackOverflow code snippet (as of 2018) contained a bug that was only fixed 9 years later?
Submission
In your submission, please include answers to any questions asked on the assignment page in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in your README file as well. Finally, include answers to the following questions:- Describe what you did, how you did it, what challenges you encountered, and how you solved them.
- Please answer any questions found throughout the narrative of this assignment.
- If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
- Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
- Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
- Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
- Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).
Assignment Rubric
| Description | Pre-Emerging (< 50%) | Beginning (50%) | Progressing (85%) | Proficient (100%) |
|---|---|---|---|---|
| Algorithm Implementation (15%) | The algorithm fails on the test inputs due to major issues, or the program fails to compile and/or run | The algorithm fails on the test inputs due to one or more minor issues | The algorithm is implemented to solve the problem correctly according to given test inputs, but would fail if executed in a general case due to a minor issue or omission in the algorithm design or implementation | A reasonable algorithm is implemented to solve the problem which correctly solves the problem according to the given test inputs, and would be reasonably expected to solve the problem in the general case |
| Code Quality and Documentation (15%) | Code commenting and structure are absent, or code structure departs significantly from best practice, and/or the code departs significantly from the style guide | Code commenting and structure is limited in ways that reduce the readability of the program, and/or there are minor departures from the style guide | Code documentation is present that re-states the explicit code definitions, and/or code is written that mostly adheres to the style guide | Code is documented at non-trivial points in a manner that enhances the readability of the program, and code is written according to the style guide |
| Writeup and Submission (70%) | An incomplete submission is provided, or the README file submitted is blank | The program is submitted, but not according to the directions in one or more ways (for example, because it is lacking a readme writeup or missing answers to written questions) | The program is submitted according to the directions with a minor omission or correction needed, including a readme writeup describing the solution and answering nearly all questions posed in the instructions | The program is submitted according to the directions, including a readme writeup describing the solution and answering all questions posed in the instructions |
Please refer to the Style Guide for code quality examples and guidelines.