Lab Exercise: Debugging and GIT Practice

This exercise is intended for you to practice debugging inheritance hierarchies and to practice recovering from GIT mistakes. You are also encouraged to use IntelliJ's Debugger to find bugs in the code, in the previous lab, as well as simply understanding how the unfamiliar code works.

Submission

There will not be an official submission for this exercise, instead show your progress to a UTA during lab when you think you are finished to get feedback.

Resources

• How to undo (almost) anything with GIT by Joshua Wehner
• GIT stashing and Cleaning from the Pro Git book

Specifications

For each bug you find:

• Comment out the buggy code
• Write a comment telling the cause of the error
• Write the correct code that fixes the error

Buggy Programs

In pairs, complete the debug the following programs using your forked version of the lab_pig project. After each, add, commit, and push your changes to the code before continuing on to the next.

Game of Pig

The game of Pig is a point-based dice game in which the first player to score at least 100 points is the winner. This implementation includes a spinner that randomly generates pig noises to supplement the die rolls.

On a player’s turn, they roll a 6-sided die and spin the spinner:

• If the spinner lands on “GRUNT” the player loses all their points for the game so far and their turn is over.
• If the die roll is 1, the player loses the points gained on the current turn only, and the turn is over.
• For any other roll/die combination, the die roll contributes to the points accumulated for this turn.

The player can then decide to play again, risking the turn points, or to "hold" — that is, keep the points for the turn and cede the turn.

There are several bugs in the given code (you do not need to fix them in the order listed here, the numbering is just for reference):

1. Game throws a NullPointerException in the winner() method
2. Sometimes the spinner gives an ArrayIndexOutOfBounds Exception
3. The die sometimes rolls a 0
4. The game does not end when a player gets at least 100 points
5. The ComputerPlayer’s name gets printed as null instead of "R2D2"
6. Spinning "GRUNT" does not make the player lose all their points
7. A 1 and "GRUNT" combination results in the player losing their turn, but not all their points

After each bug you fix, use add and commit to "record" your progress through the exercise. Then push the commits when you are done.

GIT Practice

No matter how experienced you become with GIT, at some point you will make a mistake an commit or push something you do not want in the repository. Certainly, making smaller commits and paying attention when you commit will always be the first and best defense against mistakes (as well as never using git add .). To that end, we recommend using these two GIT commands before all of your commits to ensure you know exactly what is being changed:

• git diff: show the differences between the current, edited, version of a file and the latest version in the repository
• git status: show the status of all files in the GIT folder (untracked, tracked and changed, or added for this commit)

However, once you have committed a mistake (pun intended), it is useful to be able to perform an "undo" — sometimes it will be possible to simply update the last action, but sometimes it may require creating a new commit that over writes previous changes. As long as the mistake is fixed, the history you leave is less of a concern for this course. Some GIT commands that will be useful include:

• git reset: rewinds your repository’s history all the way back to the specified commit, as if those commits never happened!
• git revert: create a new commit that is the opposite of a given commit
• git stash: save your modified tracked files on a stack of unfinished changes that you can reapply at any time
• git rebase: this is an advanced command, with many options, that attempts to smartly combine commits in a variety of ways. It is very popular (so you will see many articles about it) and very easy to mess up (so we do not recommend using it until you are very comfortable with GIT)

The above resource as well as this more humorous version have more details about each command, including different options for each.

With your partner, practice at least the following scenarios on this repository to practice making and fixing GIT mistakes:

• Undo the last commit
• Change the commit message of the last commit
• Make some changes and stash them, then make some more changes and commit them, then retrieve your stashed work and commit that
• Undo one of your bug fixes (so the code has that bug again)
• Remove the file .gitignore (note the leading period) from your project, then run the (terrible) command git add ., then see what was added using git status, finally undo the add by reseting the repository back to its latest version
• Stop GIT from tracking further changes to the README.md file (i.e., remove it from GIT's control)

Pair Programming

Labs in this course expect you to work either in pairs or with your project team.

Professionally, this practice is called Pair Programming: working closely with another programmer, sharing a "single computer" that we will simulate using a shared computer, shared repository or use IntelliJ's new Code With Me feature. To ensure both people do some coding, you will switch which person actually writes the code every 10-15 minutes (in industry this switch happens only 1-3 times per day). The person who is not actively coding can be advising, suggesting better names, looking up documentation, or searching the Internet for solutions to small problems you are likely to face, but not multi-tasking (i.e., doing their own work or socializing).