This is a two player darts scoring application. Users can set the score limits to 501 or 301. It will provide previous scores hit and also possible checkouts. It will not allow impossible scores, impossible checkouts or empty inputs.
Users can choose how many sets and legs they wish to play for. After the match has finished, users will have the options to look up match statistics, play again or go to the home screen.
Increased readability and modularity throughout the program. Also decreased the repetitiveness of the code where possible.
Custom made objects were used to check for possible checkouts when a certain score was reached. The objects were iterated over, looking for a value to be matched, and assigned the key to an output to give the user their best possible checkout route.
Utilised for checking impossible scores, impossible finishes and assigning each players' scores list
Were used for things such as: points, legs, sets and statistics; which had to be updated constantly
Allowed different screens to be accessed, without having to refresh the page, when working with this Single Page Application.
Increased readability and broke the code up into sections
This project increased my awareness of fundamental approaches to be taken when creating a program. Breaking the code down into smaller functions keeps the program structured, understandable, and reusable. Using clear variable names along with utilising comments enhances readability.
Refactoring the project after a couple of months away was an invaluable experience. It changed the way I thought about the implementation and gave me different perspectives on the software. Refactoring improves the design of the software, makes the software easier to understand, helps to find bugs and also helps in executing the program faster.
Constant testing of the application was necessary to not miss any bugs or unwanted behaviours in the application.