You have already used the basic debugging idea:
Pause the program and inspect its state.
A breakpoint gives you control over where that pause should occur.
The best breakpoint is not simply a line that is easy to click.
It is a line placed where the program state will help answer the question you are investigating.
Suppose a soccer application decides whether a player should appear in an available-player list.
You want to know:
What is the player's availability value immediately before the program makes the decision?
That question suggests where the breakpoint belongs:
before the decision is evaluated.
If you pause much earlier, the relevant value may not exist yet.
If you pause much later, the program may already have followed a path.
Open the correct source file.
Locate the statement where you want execution to pause.
Use Visual Studio's breakpoint control in the editor margin or the course-provided breakpoint command.
A breakpoint is normally shown visually beside the source line.
The exact appearance can vary by Visual Studio version and theme.
What matters is that Visual Studio now knows to pause when execution reaches that location.
Run the supplied application with the debugger.
The program executes normally until it reaches the breakpoint.
When the breakpoint is hit, Visual Studio pauses execution and highlights the current location.
At that moment:
That boundary is what makes a breakpoint useful.
While paused, inspect the values relevant to your question.
If the decision depends on:
isAvailable
look for the current value associated with that state.
Then compare the observation with your prediction.
For example:
I expected
isAvailableto betrue, and the debugger showstrue.
or:
I expected
true, but the debugger showsfalse.
The second observation gives you a specific difference to investigate.
A breakpoint before object creation cannot show the completed object state created later.
A breakpoint after several changes may show the final value without revealing which statement changed it.
Choose a location based on the moment you need to observe.
Useful moments include:
You can place several breakpoints, but filling the source with pauses can make execution difficult to follow.
Start with the breakpoint that best answers the current question.
Add another only when you need another observation point.
Debugging is clearer when each pause has a purpose.
Visual Studio includes a Breakpoints window that can show breakpoints in the current debugging environment.
This is useful when you have more than one breakpoint and need to see which ones are active.
Depending on the current Visual Studio version, the window can also provide controls for enabling, disabling, removing, or organizing breakpoints.
At this stage, use it mainly to answer:
Which breakpoints currently exist, and which are active?
You do not need advanced breakpoint conditions yet.
Sometimes you want the program to run past a breakpoint without permanently removing it.
Disabling a breakpoint can preserve its location while preventing it from pausing execution.
That can be useful while comparing two different execution points.
Use the controls provided by your current Visual Studio environment.
Old breakpoints can create surprising pauses later.
When you are finished investigating a location, remove or disable the breakpoint.
A clean debugging setup makes the next investigation easier to understand.
A breakpoint does not tell you what the program should do.
It gives you an opportunity to observe what the program is doing.
Use three sources together:
Requirement — what should happen.
Source code — what instructions are written.
Debugger state — what values exist at the selected point in execution.
When those three disagree, you have a focused debugging question.