|
I would love for people to review my code and provide any helpful feedback if there are more effective and concise ways of coding this. Thank you enum Moves: Int, CaseIterable { // Listed in order of appearance case rock case paper case scissors
} enum Players: Int, CaseIterable { // Listed in order of appearance case player case app case none
} enum Results: Int, CaseIterable { // Listed in order of appearance case win case loose case tie
} struct ContentView: View {
} struct ContentView_Previews: PreviewProvider { static var previews: some View { ContentView() } } |
|
The 2 things that jump out are: It's more complicated than it needs to be, and it is missing some things. The challenge was to have the app choose a random move, then tell the player whether they should win or lose (in your case also maybe tie) and then the player will make their choice accordingly. I can't see where you show these details to the player, and based on the code, it seems to be completely random. For your 3 types, Moves, Players and Results, these are not all necessary. Moves adds no benefit here. You can iterate over your array in your picker. Everything else works with just that. Players should not have a Results may provide some benefit, but ultimately, you can just use a string to display the message. This reduces the complexity for tip: appsScore (and the other app related variables) should drop the additional s. I understand you mean app's Score, but it is usually much cleaner to just say appScore. Just something to keep in mind... no big deal here. You also are not making use of the
Now part of the challenge was in determining the winning hand in a way that would not require such explicit checks. One approach would be to look at the relationship between them. Rock loses to Paper ( Your also assessing the round winner within the makeAppsMove function. But the player hasn't even made their choice yet. Bonus Tip: You can use a different symbol for rock if you like: circle.grid.hex.fill You completed a project. That's great. And now you get to refactor it, and work on it to make it better. That's even more fun... but can be frustrating. If you want to discuss things even further, maybe look at how you could implement your enums in a different way to achieve the end result a little "better" let me know. Great start... hope you keep at it. |
|
Thank you very much @MarcusKay for not only taking time to review my code but also for giving some feedback. That's very awesome, and appreciated. I will review your feedback and make a plan to refactor. Thanks again :) |
SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.
Sponsor Hacking with Swift and reach the world's largest Swift community!
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.