"Deal Or No Deal"-style game in Java

This game is explained here.

Could this code be more efficient?

The Game Class

```
import java.util.List;
import java.util.Arrays;
import java.util.Collections;

public class Game {

private Case[] cases = new Case[26];
private Player player = new Player();
private Banker banker = new Banker();
private int myAmount = 0;
private int turn = 1;
private int briefCases = 26;
private int casesToRemove = 6;
private int offer = 0;
private boolean gameContinue = true;

public void caseSetup() {

List values = Arrays.asList(1, 5, 10, 100, 500, 750, 1000, 20000, 50000, 75000, 95000,
100000, 150000, 250000, 350000, 400000, 450000, 500000, 600000, 700000, 25, 900000, 1000000, 1500000, 300, 900000);

Collections.shuffle(values);

for (int i = 0; i 0;counter--){
player.removeCase(counter,cases);
briefCases--;
showCase();
}
offer = banker.getOffer(turn,cases,myAmount);
gameContinue = player.dnd();
casesToRemove--;
turn++;
}else if(briefCases == 1){
player.removeCase(1,cases);
offer = banker.getOffer(turn,cases,myAmount);
gameContinue = player.dnd();
casesToRemove--;
briefCases--;
turn++;
}
else{
player.removeCase(1,cases);
offer = banker.getOffer(turn,cases,myAmount);
gameContinue = player.dnd();
casesToRemove--;
briefCases--;
turn++;
}
}
finishGame();
}
public void finishGame(){
if(briefCases == 0){
System.out.println("You've rejected the Offer of banker");
System.out.println("You've won "+myAmount+"And your Ca

A few comments:

• Try to keep the scope of your variables as low as possible. Don't not be afraid of local variables.

• Consistently follow naming conventions. Sometimes your method names are in UpperCamelCase. That should be reserved for class and interface names only. Also method names should be verbs or verb phrases. (EDIT: This used to say variable names should be verbs. That is completely wrong, and it was a sleep-deprived mistake on my part to include that. Variable names should be lowerCamelCase descriptive nouns.)

• Complicated if statement can almost always be refactored away. Sometimes they need to move to their own class, but most of the time you can get rid of them altogether. See Strategy Pattern, Replace Type Code with Subclasses, Abstract Factory Pattern

• Whitespace is your friend. It makes your code prettier and easier to read.

average = myAmount+total/numOfSamples should be

average = myAmount + total / numOfSamples

• Magic number suck. Firmly eschew them.

-
Comments are your friend. A lot of the stuff you had was confusing the first couple go throughs because of a lack of comments. They can help you come up with better variable and function names, do better decomposition, and pay more attention to refactoring (all for the low, low price of $0.00!)

For every line of code in your program:

• Think of a comment that explains both what you're doing and why you're doing it. You should only add comments regarding why your doing something to your actual code, but thinking about what your doing helps with the refactoring.

• If it's a comment on a field or constant and it's not already redundant, consider refactoring your variable name so that the comment becomes redundant. If there's still a why explanation needed, then add a comment, otherwise your code should mostly be self-documenting.

• Comments before functions should be considered required before your function is complete. There is always a why to each function. However, thinking about the what can help you refactor the names of your functions. Also if you can't think of a good short name for your function it may be a sign that it is doing too much. Decompose.

• Comments before classes are much like comments before functions; they are required, they can help you refactor the names of your classes, and they help get rid of God Classes.

• Comments within functions that don't seem redundant are probably an indicator for more decomposition unless your doing a complicated algorithm. Decompose.

• This code is begging to be extendable. Text-based is fine to start with, but sometimes there's that nagging feeling that you should change it to a GUI (or change the text interface or w/e). Design with that in mind. Your code is so tightly coupled a few small changes to the UI would make you have to go through the whole thing. You probably want more classes to separate out the different functionalities. Consider MVC.

StackExchange Code Review Q#4800, answer score: 8