Draft: Resolve "Add break at the end of SHOOTING_PID state"

Add break at the end of SHOOTING_PID state.

closes #46

What?

Adds break at the end of SHOOTING_PID state.

Why?

This is needed to prevent an infinite loop of updating and possible future issues.

How?

Typed "break" followed by a semicolon.

Testing?

This code was tested as needed.

Review Checklist

The following sections detail some items that reviewers should think about and mark the checkbox for when they agree. The programmers who are listed below are the ones responsible for reviewing this merge request. Before this merge request gets merged in, each reviewer should complete a thorough review of the code and mark all the checkboxes as completed.

Josh Langley (@joshlangley )

• This merge request benefits the overall health of the codebase
• The code has been tested appropriately
• The commit messages have been reviewed and conform to the git standards.
• Every line of code I was assigned to review has been reviewed
• The context of the changes has been taken into consideration. These code changes still benefit the overall health of the codebase.
• The merge request looks good to me and should be merged

---

Merge Request Process Overview

The Merge Request (MR) process is the process through which team 2996 will review code and merge it into the main branch. This process is crucial to developing high quality, peer reviewed code that all team members understand and agree with. The point of the merge review process is to give and receive constructive feedback on code that will be used.

The reviewers named above are responsible for reviewing this merge request at a minimum. If additional team members would also like to review the merge request, they are free to jump in.

This process is a great place to practice the First Robotics concept of gracious professionalism. Comments should always be constructive, and focus on the code, not the author of the code. For example, it is productive to comment:

Why did you choose to implement it this way? I think it could be done easier using xyz.

And it is unproductive to comment:

The way you implemented it is bad, you should have realized you can use xyz to do that.

Comments on our code help everyone- the reviewer and the author- get on the same page about why and how things changed in the codebase. They are a great opportunity to learn from others and share your knowledge with your teammates.

Comments do not only have to be about things that could improve. It is nice to also comment on things an author did well. Pointing out what people did well will encourage them to do that again in the future.

Once all reviewers have had a chance to review a merge request and leave comments, the code author must go through and resolve all comments. Often this means changing the code, or responding to comments several times until the reviewer and author agree about a change. Once the reviewer is satisfied the code author has completed all the requested changes, the reviewer can resolve the thread in gitlab.

Once all threads have been resolved and all reviewers have checked the box above saying they think the MR should be merged, the merge request can be merged to main by a repository maintainer.