COMP 2012H Honors Object-Oriented Programming and Data Structures

Lab 1 Eclipse, Fundamentals of C++, and Program Flow Control

Common Errors

  1. Negative health, e.g. if Player 1 has only 2 health and then Player 2 uses 3 rockets to attack, the game ends with Player 1's health equal to -1 (should be 0). However, not a vital problem.

  2. If the program was run as a single executable program, upon the termination of the program, it exits immediately instead of pausing at the last output so that the user can not clearly see the result of the game. (Not a vital problem, just by using system("pause") or waiting for a dummy input can solve this issue.)

  3. Forgetting to ask the Player again when receiving an invalid input.

  4. Forgetting to ask the player to choose a different action if they tried to build too many barriers/rockets, or tried to launch zero rockets.

  5. Forgetting to play the Rock-Paper-Scissors game again after every round.

  6. Not correctly processing both players actions for each round (e.g. Only the winner of the Rock-Paper-Scissors game gets an action, or Player 1 always gets two actions).

  7. Forgetting to set the correct player turn sequence after Rock-Paper-Scissors game (e.g. Player 1 always goes first).

  8. Not ending the game immediately if the first player for that round won (e.g. Player 2 goes first and surrenders, but the game still asks for Player 1 action).

  9. Mixing up Barriers and Rockets variables (e.g. Choosing to build rockets incorrectly builds barriers instead).

  10. Incorrect or missing output messages, especially for the common cases of building too many barriers/rockets.

  11. Not realizing there is a skeleton code, and coding everything from scratch. Not exactly a coding error, but surprisingly common and also one of the main causes of not being able to finish and demo the lab without bugs on-time.

  12. Inconsistent coding style and indentation, hard to read the code, and more importantly hard to explain the code to others.

  13. Unnecessary use of recursion to do looping. This is particularly dangerous when asking again after invalid input, as theoretically we can use a script or keyboard macro to keep inputting invalid inputs and cause a function stack overflow. To explain, each function call has a memory overhead, and since in a recursive function every level of the recursive function call doesn't return until the lower levels return, an attacker can abuse this to crash the program/system by consuming too much memory via an infinite recursion. Therefore, only use recursion to solve problems with a well-defined limit to the recursion depth, not as a way to implement a while loop that depends on user input.