Junilu Lacar wrote:Try refactoring your code so that you're not referencing game so much. The code gets very verbose and noisy when you have game.playerStick and game.playerHit and game.whatever all over the place.
Kent Beck wrote:If you don't know how you're going to test your code, then you have no business writing it.
Junilu Lacar wrote:Another way you can gauge the maintainability of your code is to introduce new requirements.
Here's a couple:
How easy/hard would it be to change the code so that you're also displaying what particular cards are being dealt?
For example, if I wanted the game to go something like this:
Welcome to BlackJack!
Your starting hand: 8♥ 7♦
Would you like to Hit or Stand (H, S)? H
Your hand: 8♥ 7♦ K♠
Bust. Sorry, you lose.
2. Have logic that automatically uses 1 or 11 for an Ace card, depending which value makes the hand better and avoids a bust.
3. What if you wanted to make a GUI instead of character interface? How easy would it be to display images of cards.
4. What if instead of just using a PRNG (Pseudo Random Number Generator), you'd actually simulate combining N number of standard 52-card decks, shuffling them all, and dealing from the combined deck? How hard/easy would it be to make that change?
These are all good exercises that will help you experience for yourself the kind of impediments early design decisions can create in terms of maintainability and enhancement.
Junilu Lacar wrote:Good, but try it by starting with what you already have instead of starting over from scratch. Also, try to write automated tests as you go. How would you test randomness?
Don't mess with me you fool! I'm cooking with gas! Here, read this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton