[Logo]
Forums Register Login
Need help. Not getting proper output.


This is my code. The game should end when a player reaches POINTS_TO_WIN, but it just keeps going. Any help would be appreciated.
Where is the player class ?
 
Shubham Semwal wrote:Where is the player class ?

WhoWon and Die classes ?
and the class with main(). It's difficult to walkthrough without executing the program.
 
Shubham Semwal wrote:WhoWon and Die classes ?
and the class with main(). It's difficult to walkthrough without executing the program.[/quot

Here is the die class class, the whoWon is not there, it was just something else I was trying to solve the issue didnt work. Not really part of the program.
 
You're using way too many break; statements. You're not using your looping conditions correctly. Where are you setting gameON to false?
Can you show an example run?
You've got lots of println's in there (which is good for debugging) so it would narrow down where the issue is.
(1 like)
Your loop should roughly go like this:
Oh, and coiuld you format the code?
That while loop whould look something like:

which would help with seeing the flow.
Whitespace is free, so squeezing stuff onto a single line is not saving you anything.

And for Stephan, it's never set false because Shawn is using break to get out of the loop.
I'd replace the breaks with gameON = false, personally.
 
Dave Tolls wrote:Can you show an example run?
You've got lots of println's in there (which is good for debugging) so it would narrow down where the issue is.


I'm not sure what you mean by "example run", but here is some output. Once player one hit 11 points the game should have ended but its not. Sorry still new to Java. We dont go over debugging til next week.

(1 like)
That's because you're still in the turn loop, not in the game loop.

The game should end when the player hits 'e'. If you want to do this automatically, you should include that logic in your turn loop.

Take a look at the example code I posted above, and include another expression that determines the value of rollAgain.
 
Stephan van Hulst wrote:That's because you're still in the turn loop, not in the game loop.

The game should end when the player hits 'e'. If you want to do this automatically, you should include that logic in your turn loop.

Take a look at the example code I posted above, and include another expression that determines the value of rollAgain.


Thanks very much, I've been up for to many hours and didnt even see that I had to end the game manually.
 
Stephan van Hulst wrote:That's because you're still in the turn loop, not in the game loop.

The game should end when the player hits 'e'. If you want to do this automatically, you should include that logic in your turn loop.

Take a look at the example code I posted above, and include another expression that determines the value of rollAgain.


That's exactly what we needed to see.
It shows us where it stops (or goes wrong) so we can then focus on that bit of code, otherwise we have to run it ourselves or try and work through the code by sight (which is horribly inefficient).

This is (essentially) basic debugging. Logging (in this case simply printing to the console) so you can see where in your code you are going. The next step would have been printing out values at each step so you could make sure everything looked the way you thought it would look.
(1 like)
 
Shawn Gordian wrote:I've been up for to many hours and didnt even see that I had to end the game manually.

First off, welcome to the wonderful world of programming!

By now you should see the kind of trouble you can get yourself into if you don't organize your program well. What you have written is a good example of what's called "spaghetti code" - a jumble of nested conditional branches, multiple unstructured breaks in execution flow, and loops that don't terminate clearly and cleanly. You have committed a lot of rookie mistakes and that's fine, everyone has done the kind of things at some point. You need to learn from your mistakes though. The worst thing you could do is walk away from this program just because it works now and continue to program the way you did with this problem. That's only going to get you into bigger and stickier problems later.

(1 like)
One thing that I find very lacking in the way new programmers are taught is a grounding in basic safety and cleanliness. As small school children, we're often taught basic things like washing your hands, cleaning up after yourself, putting toys away and keeping things in order, etc. These are all good habits to develop when we are children and take on throughout the rest of our lives. I think the same basic principles should be applied to teaching how to program.

Below are some of my guidelines for programming. Don't be intimidated by words like "design", "clarity", and "duplication" -- you may think that these are too advanced concepts for you but I disagree. You have already encountered them, albeit perhaps unknowingly, from the very first program that you write.

Guidelines for Programmers

While you're programming, as often as you can, stop and check to make sure that...
1. You're using names that make sense. Are they clear and unambiguous? If not, rename so that they are.
2. You're not repeating yourself unnecessarily. If you are, eliminate duplication by extracting to a method.
3. You're telling a clear, coherent story. Don't mix details with generalities; keep them separate. Prefer to tell the general story first. Hide the details.
4. You're following the 4 Rules of Simple Design. If you're doing 1 to 3 above, you're already doing that for the most part.

Remember, the best way to eat an elephant is one bite at a time. Keep things small and manageable. And don't be a glutton.

And most of all, learn how to write automated tests for your code. Nothing slows you down more than not being sure if your program works, if you've broken anything, or why that thing that used to work before doesn't seem to work anymore. Learn how to use JUnit or something like it. Tools like this will save your life. Literally. Seriously.
(1 like, 1 cow)
Here's an example of how those guidelines can be applied.

Take a look at this code that you wrote.

Let's look at the name "checkForWinner". Your comments say that it returns true if there is a winner, otherwise it will return false.

Is this name clear and unambiguous? You might think so but consider this: You ask your smartass younger brother, "Hey, Billy, can you check if there was a winner in last night's lotto drawing?" and Billy goes, "Sure!" A few minutes go by and Billy hasn't come back yet. So, you yell out to him, "Hey, Billy, did you check?" Billy yells back, "No! Did you want me to?" Anyone with an annoying sibling will probably know where I'm going with this. You asked "Can you check...?" and Billy answered that indeed, he was capable of doing that thing you asked about. But he didn't actually do it. If you wanted that to happen, you should have said, "Billy, please tell me if there was a winner in last night's lotto draw."

I know that might sound silly but it boils down to one thing: semantics. Make sure that the names you use fit with the semantics of their usage. When the semantics are off, even just a little bit like what you have in that checkForWinner, the slight mental adjustments that you have to make as you read the code can be enough to cause confusion and misunderstanding. That's where bugs come from. And unclear and ambiguous code is like a damp, dark corner, where bugs like to hide and breed.

Consider this revised version of that method:

Isn't this a lot clearer and more straight to the point?

You might say, "Well, that doesn't do exactly the same thing as the previous code" and you'd be absolutely right. Here's another thing about that previous code though: it was too greedy. It tried to do too many things:
1. Check if there's a winner
2. If there's a winner, report who it was
3. Tell whoever it was who called the method whether there was a winner or not.

That previous code lacked focus, it lacked a singularity of purpose. Code without focus is confused and confusing, even when it's that small. To organize things better, you should separate responsibilities and do something like this instead:

Now, isn't that clearer and cleaner? But that's not the end of it. It leads you to more questions and possibilities for cleaning up so that you're following those guidelines.

So in all this rearranging and renaming, what you're really doing is trying to get your story straight and tell it in a clearer and more concise manner. That's what programming is really about and good programmers can write programs that tell a clear and concise story. Those who don't just create problems for themselves and others who need to work with their code.

There are a lot more examples of how you can make the code that you wrote better, especially around those loops and breaks in execution flow. But I'll leave that as an exercise for you. That's the best way to learn to be a better programmer. Happy coding!
Again thanks for the helping me see through my mistakes. Thanks for the tips and advice. I will definitely be applying them as I move forward in this in the coding world. I had to turn in the project today so I turned it in as I completed it. I will however be going back into it to clean it up and make some changes just for my own sake and some more practice.
 
Shawn Gordian wrote:I will however be going back into it to clean it up and make some changes just for my own sake and some more practice.

Great idea, and post it here too so all can benefit.
Wink, wink, nudge, nudge, say no more ... https://richsoil.com/cards


This thread has been viewed 684 times.

All times above are in ranch (not your local) time.
The current ranch time is
Dec 18, 2017 08:13:40.