Draft: Resolve "code throws null pointer when auto chooser has no selection."

Closes #81

(Merge Request Title)

What?

set DoNothing as the default auto program.

Why?

Without a default program, the auto chooser will throw a null pointer exception. DoNothing will be the default to minimize possible failure with more complex autonomous programs.

Testing?

This code has not yet been tested.

Reviewer Tasks

The following tasks should be completed by a reviewer prior to this code getting merged in. If you would like a reviewer to test any of your code, explain in detail all the steps necessary to test the code. Only one reviewer must complete these tasks. Once a reviewer has completed these tasks, they should mark the checkbox.

• compile code locally
• run the code, and test that DoNothing is set as the default.

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.

(Reviewer Name)

• 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.
• Comments in the code are clear and useful, and mostly explain why instead of what
• 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

(Reviewer Name)

• 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.
• Comments in the code are clear and useful, and mostly explain why instead of what
• 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.