Unit 2 ‐ Lesson 1
A bug is a mistake in the code arising from faulty reasoning (i.e., your mental model of the problem or solution is incorrect) or technical inexperience. You have probably already made mistakes in the homework and have spent considerable time fixing them. This process of fixing programming errors is known as debugging - removing bugs. Bugs are an unavoidable problem because humans write code, and humans are imperfect, and time and resources for software development are limited. The developer must ultimately choose how to allocate resources - between fixing bugs, adding new software features, and determining what the limitations of those features should be. Because bugs are generally a "nuisance" that distract from adding new features, there are myriad tools to help you detect, fix, and prevent bugs efficiently.
You have probably already used printing to the console as a debugging tool. When you developed the operations for your calculator, such as the factorial or square root operations, you likely printed out information to the console to help check your work. For example, you know that the square root of 9 is 3; if you put in 9 and the square root operator, the result should be 3. If it is not 3, then there is a bug in the code that must be rooted out.
You can use the console to print out intermediate results between the input (9) and the final result (3). This helps check the logic of the program.
However, console output can be a rather slow/inefficient way to debug, and sometimes there is simply too much information to print out to the console, or you are not totally sure what should even be printed.
Breakpoints were created to solve the problems just mentioned. They allow you to pause the code at a certain line and look at the value of every variable at that moment. This helps you explore the current state of the code, rather than printing out predefined values. This saves time because some programs can take a long time to run; if you wanted to print out a variable to console, then decide that you need more information about the current state of the program, you must stop the program, add more console logging statements, then re-run the program. Breakpoints are superior to this method because you can look at many variables without predefining which ones you want to look at.
Breakpoints are very easy to use in Visual Studio. You can add a breakpoint by right-clicking on a line and going to Breakpoint -> Insert Breakpoint. A faster way to accomplish the same thing is to click on the gray bar to the left of the line numbers. A red circle should appear at that location, and the code line should be highlighted red.
If you start your program, the code before the breakpoint will be executed. The line will be highlighted yellow when the breakpoint is "hit". The line of the breakpoint itself will not be executed.
You can explore the code by mousing over variables. For example, you can see that the variable i here has the value 1.
You can now click the "Continue" button at the top (the green arrow, where the button to start your program used to be) to continue executing the code. The code will continue until another breakpoint is hit. Another option is to exit the program, which is the red square at the top, to the right of the "Continue" button.
You can also add conditions to breakpoints, so that the code only hits the breakpoint when the condition is met. This can sometimes cause the program to be quite slow, but it is a useful feature. After adding a breakpoint, right-click on it (the red circle) and select "Conditions...". You can now add a conditional statement that will specify the condition for when the breakpoint is hit. For example, I have added the condition i == 2, which will cause the breakpoint to be hit when i is equal to 2.
- Implement a new operator,
^, which computes an exponent.
For example, if a user inputs:
3
^
4
The result should be 81 (i.e., 3^4). Use breakpoints to stop the program at the beginning of your method (the opening curly bracket), the beginning of the loop body, the end of the loop body, and the end of the method. When each breakpoint is hit, look at the variables which store your data (intermediate results, etc.).