# Golf ACSL Help

Page 1 of 1

## 9 Replies - 3943 Views - Last Post: 20 December 2009 - 01:58 PMRate Topic: //<![CDATA[ rating = new ipb.rating( 'topic_rate_', { url: 'http://www.dreamincode.net/forums/index.php?app=forums&module=ajax&section=topics&do=rateTopic&t=145523&amp;s=a45e9d99b0969df8a8cad9290b7f81e5&md5check=' + ipb.vars['secure_hash'], cur_rating: 0, rated: 0, allow_rate: 0, multi_rate: 1, show_rate_text: true } ); //]]>

### #1 10rbacon

Reputation: 0
• Posts: 5
• Joined: 14-December 09

# Golf ACSL Help

Posted 14 December 2009 - 04:26 PM

PROBLEM: In the sport of golf, scoring is based upon what a normal score should be for a particular hole on a course. That normal score called “par” is based upon the length of that hole measured from the tee, the start point, to the green, the end point. For the vast majority of golf courses and for this problem par values will be either 3, 4 or 5. Golf scores can be reported in three ways. The first way is to report cumulative score. That is, the player scored a 68 after playing the standard 18 holes. The second way is to report the cumulative score in relation to par. If par for the course ( the sum of the par values of all the holes) is 72, then the score reported as 68 would be 4 under par. A score of 75 would be 3 over par. A score of 72 is reported as par. The third way is by holes won. A player wins a hole when his score is lower than his opponent’s score.

INPUT: There will be 9 input lines. Each line will contain 3 positive integers. The first integer will give the par value of each of the nine holes. The second integer will give the score for player A on the same nine holes. The third integer will give the score for player B on the those nine holes.

OUTPUT: There will be five outputs. Print the following:

1. The cumulative score for each player with the better score (the smaller number) first.
2. The score in relation to par for the better score.
3. The score in relation to par for the other player.
4. The number of holes won by the player with the better score.
5. The sum of the scores on a the hole that is the highest for all the holes played.
______________________________________________________________
INPUT:
1. 3,2,3
2. 4,5,5
3. 5,6,6
4. 4,3,4
5. 4,3,4
6. 4,4,5
7. 5,5,6
8. 3,3,3
9. 4,4,5

OUTPUT:
1. 35, 41
2. 1 under par
3. 5 over par
4. 6
5. 12

Is This A Good Question/Topic? 0

## Replies To: Golf ACSL Help

### #2 pbl

• There is nothing you can't do with a JTable

Reputation: 8362
• Posts: 31,955
• Joined: 06-March 08

## Re: Golf ACSL Help

Posted 14 December 2009 - 04:58 PM

[rules][/rules]

### #3 10rbacon

Reputation: 0
• Posts: 5
• Joined: 14-December 09

## Re: Golf ACSL Help

Posted 14 December 2009 - 09:35 PM

```
import java.util.Scanner;
import java.util.Arrays;
import java.util.ArrayList;

public class ACSLG{
public static void main(String[] ralph){
Scanner input = new Scanner(System.in);
int[] A = new int[9];
int[] B = new int[9];
int[] C = new int[9];
int[] D = new int[9];

int par = 36;
int one = 0;
int two = 0;
int three = 0;
int four = 0;

for (int i = 0; i < 9; i++){

A[i] = input.nextInt();
B[i] = input.nextInt();
C[i] = input.nextInt();
D[i] = input.nextInt();

}

for(int p = 0; p < 9; p++){
one += A[p];
}

for(int q = 0; q < 9; q++){
two += B[q];
}
for(int r = 0; r < 9; r++){
three += C[r];
}
for(int s = 0; s < 9; s++){
four += D[s];
}

{
if(two == par)
System.out.println("par");
if(two < par)
System.out.println(par - two + " under par");
if(two > par)
System.out.println(two - par + " over par" );
}

{
if(one == par)
System.out.println("par");
if(one < par)
System.out.println(par - one + " under par");
if(one > par)
System.out.println(one - par + " over par" );
}

{

ArrayList<Integer> middle = new ArrayList<Integer>();
for(int o = 0; o < 9; o++){
if(A[o] < B[o] && A[o] < C[o] && A[o] < D[o]);

}

}

{

int[] totals = new int[4];
totals[0] = one;
totals[1] = two;
totals[2] = three;
totals[3] = four;

Arrays.sort(totals);
System.out.println(totals[0]);

for(int p = 0; p < 9; p++){

}

}
}
}

```

This post has been edited by 10rbacon: 14 December 2009 - 09:35 PM

### #4 pbl

• There is nothing you can't do with a JTable

Reputation: 8362
• Posts: 31,955
• Joined: 06-March 08

## Re: Golf ACSL Help

Posted 14 December 2009 - 09:46 PM

A, B, C, D p, q, r, s what are these ?

Steve McConnell
Code Complete 2nd edition
Microsoft Press

Creating Short Names That Are Readable
The desire to use short variable names is in some ways a remnant of an earlier age of computing. Older languages like assembler, generic Basic, and Fortran limited variable names to 2–8 characters and forced programmers to create short names. Early computing was more closely linked to mathematics and its use of terms like i, j, and k as the variables in summations and other equations. In modern languages like C++, Java, and Visual Basic, you can create names of virtually any length; you have almost no reason to shorten meaningful names.

If circumstances do require you to create short names, note that some methods of shortening names are better than others. You can create good short variable names by eliminating needless words, using short synonyms, and using any of several abbreviation strategies. It's a good idea to be familiar with multiple techniques for abbreviating because no single technique works well in all cases.

General Abbreviation Guidelines
Here are several guidelines for creating abbreviations. Some of them contradict others, so don't try to use them all at the same time.

- Use standard abbreviations (the ones in common use, which are listed in a dictionary).

- Remove all nonleading vowels. (computer becomes cmptr, and screen becomes scrn. apple becomes appl, and integer becomes intgr.)

- Remove articles: and, or, the, and so on.

- Use the first letter or first few letters of each word.

- Truncate consistently after the first, second, or third (whichever is appropriate) letter of each word.

- Keep the first and last letters of each word.

- Use every significant word in the name, up to a maximum of three words.

- Remove useless suffixes—ing, ed, and so on.

- Keep the most noticeable sound in each syllable.

Be sure not to change the meaning of the variable.

Iterate through these techniques until you abbreviate each variable name to between 8 to 20 characters or the number of characters to which your language limits variable names.

Phonetic Abbreviations
Some people advocate creating abbreviations based on the sound of the words rather than their spelling. Thus skating becomes sk8ing, highlight becomes hilite, before becomes b4, execute becomes xqt, and so on. This seems too much like asking people to figure out personalized license plates to me, and I don't recommend it. As an exercise, figure out what these names mean:

ILV2SK8
XMEQWK
S2DTM8O
NXTC
TRMN8R

You can fall into several traps when creating abbreviations. Here are some rules for avoiding pitfalls:

Don't abbreviate by removing one character from a word Typing one character is little extra work, and the one-character savings hardly justifies the loss in readability. It's like the calendars that have "Jun" and "Jul." You have to be in a big hurry to spell June as "Jun." With most one-letter deletions, it's hard to remember whether you removed the character. Either remove more than one character or spell out the word.

Abbreviate consistently Always use the same abbreviation. For example, use Num everywhere or No everywhere, but don't use both. Similarly, don't abbreviate a word in some names and not in others. For instance, don't use the full word Number in some places and the abbreviation Num in others.

Create names that you can pronounce Use xPos rather than xPstn and needsComp rather than ndsCmptg. Apply the telephone test—if you can't read your code to someone over the phone, rename your variables to be more distinctive (Kernighan and Plauger 1978).

Avoid combinations that result in misreading or mispronunciation To refer to the end of B, favor ENDB over BEND. If you use a good separation technique, you won't need this guideline since B-END, BEnd, or b_end won't be mispronounced.

Use a thesaurus to resolve naming collisions One problem in creating short names is naming collisions—names that abbreviate to the same thing. For example, if you're limited to three characters and you need to use fired and full revenue disbursal in the same area of a program, you might inadvertently abbreviate both to frd.

One easy way to avoid naming collisions is to use a different word with the same meaning, so a thesaurus is handy. In this example, dismissed might be substituted for fired and complete revenue disbursal might be substituted for full revenue disbursal. The three-letter abbreviations become dsm and crd, eliminating the naming collision.

Document extremely short names with translation tables in the code In languages that allow only very short names, include a translation table to provide a reminder of the mnemonic content of the variables. Include the table as comments at the beginning of a block of code. Here's an example:

Fortran Example of a Good Translation Table
C *******************************************************************

C Translation Table

C

C Variable Meaning

C -------- -------

C XPOS x-Coordinate Position (in meters)

C YPOS Y-Coordinate Position (in meters)

C NDSCMP Needs Computing (=0 if no computation is needed;

C =1 if computation is needed)

C PTGTTL Point Grand Total

C PTVLMX Point Value Maximum

C PSCRMX Possible Score Maximum

C *****************************************************************

You might think that this technique is outdated, but as recently as mid-2003 I worked with a client that had hundreds of thousands of lines of code written in RPG that was subject to a 6-character–variable-name limitation. These issues still come up from time to time.

Document all abbreviations in a project-level "Standard Abbreviations" document Abbreviations in code create two general risks:

A reader of the code might not understand the abbreviation.

Other programmers might use multiple abbreviations to refer to the same word, which creates needless confusion.

To address both these potential problems, you can create a "Standard Abbreviations" document that captures all the coding abbreviations used on your project. The document can be a word processor document or a spreadsheet. On a very large project, it could be a database. The document is checked into version control and checked out anytime anyone creates a new abbreviation in the code. Entries in the document should be sorted by the full word, not the abbreviation.

This might seem like a lot of overhead, but aside from a small amount of startup overhead, it really just sets up a mechanism that helps the project use abbreviations effectively. It addresses the first of the two general risks described above by documenting all abbreviations in use. The fact that a programmer can't create a new abbreviation without the overhead of checking the Standard Abbreviations document out of version control, entering the abbreviation, and checking it back in is a good thing. It means that an abbreviation won't be created unless it's so common that it's worth the hassle of documenting it.

This approach addresses the second risk by reducing the likelihood that a programmer will create a redundant abbreviation. A programmer who wants to abbreviate something will check out the abbreviations document and enter the new abbreviation. If there is already an abbreviation for the word the programmer wants to abbreviate, the programmer will notice that and will then use the existing abbreviation instead of creating a new one.

The general issue illustrated by this guideline is the difference between write-time convenience and read-time convenience. This approach clearly creates a write-time inconvenience, but programmers over the lifetime of a system spend far more time reading code than writing code. This approach increases read-time convenience. By the time all the dust settles on a project, it might well also have improved write-time convenience.

Remember that names matter more to the reader of the code than to the writer Read code of your own that you haven't seen for at least six months and notice where you have to work to understand what the names mean. Resolve to change the practices that cause such confusion.

### #5 10rbacon

Reputation: 0
• Posts: 5
• Joined: 14-December 09

## Re: Golf ACSL Help

Posted 14 December 2009 - 09:55 PM

pbl, on 14 Dec, 2009 - 08:46 PM, said:

A, B, C, D p, q, r, s what are these ?

Steve McConnell
Code Complete 2nd edition
Microsoft Press

Creating Short Names That Are Readable
The desire to use short variable names is in some ways a remnant of an earlier age of computing. Older languages like assembler, generic Basic, and Fortran limited variable names to 2–8 characters and forced programmers to create short names. Early computing was more closely linked to mathematics and its use of terms like i, j, and k as the variables in summations and other equations. In modern languages like C++, Java, and Visual Basic, you can create names of virtually any length; you have almost no reason to shorten meaningful names.

If circumstances do require you to create short names, note that some methods of shortening names are better than others. You can create good short variable names by eliminating needless words, using short synonyms, and using any of several abbreviation strategies. It's a good idea to be familiar with multiple techniques for abbreviating because no single technique works well in all cases.

General Abbreviation Guidelines
Here are several guidelines for creating abbreviations. Some of them contradict others, so don't try to use them all at the same time.

- Use standard abbreviations (the ones in common use, which are listed in a dictionary).

- Remove all nonleading vowels. (computer becomes cmptr, and screen becomes scrn. apple becomes appl, and integer becomes intgr.)

- Remove articles: and, or, the, and so on.

- Use the first letter or first few letters of each word.

- Truncate consistently after the first, second, or third (whichever is appropriate) letter of each word.

- Keep the first and last letters of each word.

- Use every significant word in the name, up to a maximum of three words.

- Remove useless suffixes—ing, ed, and so on.

- Keep the most noticeable sound in each syllable.

Be sure not to change the meaning of the variable.

Iterate through these techniques until you abbreviate each variable name to between 8 to 20 characters or the number of characters to which your language limits variable names.

Phonetic Abbreviations
Some people advocate creating abbreviations based on the sound of the words rather than their spelling. Thus skating becomes sk8ing, highlight becomes hilite, before becomes b4, execute becomes xqt, and so on. This seems too much like asking people to figure out personalized license plates to me, and I don't recommend it. As an exercise, figure out what these names mean:

ILV2SK8
XMEQWK
S2DTM8O
NXTC
TRMN8R

You can fall into several traps when creating abbreviations. Here are some rules for avoiding pitfalls:

Don't abbreviate by removing one character from a word Typing one character is little extra work, and the one-character savings hardly justifies the loss in readability. It's like the calendars that have "Jun" and "Jul." You have to be in a big hurry to spell June as "Jun." With most one-letter deletions, it's hard to remember whether you removed the character. Either remove more than one character or spell out the word.

Abbreviate consistently Always use the same abbreviation. For example, use Num everywhere or No everywhere, but don't use both. Similarly, don't abbreviate a word in some names and not in others. For instance, don't use the full word Number in some places and the abbreviation Num in others.

Create names that you can pronounce Use xPos rather than xPstn and needsComp rather than ndsCmptg. Apply the telephone test—if you can't read your code to someone over the phone, rename your variables to be more distinctive (Kernighan and Plauger 1978).

Avoid combinations that result in misreading or mispronunciation To refer to the end of B, favor ENDB over BEND. If you use a good separation technique, you won't need this guideline since B-END, BEnd, or b_end won't be mispronounced.

Use a thesaurus to resolve naming collisions One problem in creating short names is naming collisions—names that abbreviate to the same thing. For example, if you're limited to three characters and you need to use fired and full revenue disbursal in the same area of a program, you might inadvertently abbreviate both to frd.

One easy way to avoid naming collisions is to use a different word with the same meaning, so a thesaurus is handy. In this example, dismissed might be substituted for fired and complete revenue disbursal might be substituted for full revenue disbursal. The three-letter abbreviations become dsm and crd, eliminating the naming collision.

Document extremely short names with translation tables in the code In languages that allow only very short names, include a translation table to provide a reminder of the mnemonic content of the variables. Include the table as comments at the beginning of a block of code. Here's an example:

Fortran Example of a Good Translation Table
C *******************************************************************

C Translation Table

C

C Variable Meaning

C -------- -------

C XPOS x-Coordinate Position (in meters)

C YPOS Y-Coordinate Position (in meters)

C NDSCMP Needs Computing (=0 if no computation is needed;

C =1 if computation is needed)

C PTGTTL Point Grand Total

C PTVLMX Point Value Maximum

C PSCRMX Possible Score Maximum

C *****************************************************************

You might think that this technique is outdated, but as recently as mid-2003 I worked with a client that had hundreds of thousands of lines of code written in RPG that was subject to a 6-character–variable-name limitation. These issues still come up from time to time.

Document all abbreviations in a project-level "Standard Abbreviations" document Abbreviations in code create two general risks:

A reader of the code might not understand the abbreviation.

Other programmers might use multiple abbreviations to refer to the same word, which creates needless confusion.

To address both these potential problems, you can create a "Standard Abbreviations" document that captures all the coding abbreviations used on your project. The document can be a word processor document or a spreadsheet. On a very large project, it could be a database. The document is checked into version control and checked out anytime anyone creates a new abbreviation in the code. Entries in the document should be sorted by the full word, not the abbreviation.

This might seem like a lot of overhead, but aside from a small amount of startup overhead, it really just sets up a mechanism that helps the project use abbreviations effectively. It addresses the first of the two general risks described above by documenting all abbreviations in use. The fact that a programmer can't create a new abbreviation without the overhead of checking the Standard Abbreviations document out of version control, entering the abbreviation, and checking it back in is a good thing. It means that an abbreviation won't be created unless it's so common that it's worth the hassle of documenting it.

This approach addresses the second risk by reducing the likelihood that a programmer will create a redundant abbreviation. A programmer who wants to abbreviate something will check out the abbreviations document and enter the new abbreviation. If there is already an abbreviation for the word the programmer wants to abbreviate, the programmer will notice that and will then use the existing abbreviation instead of creating a new one.

The general issue illustrated by this guideline is the difference between write-time convenience and read-time convenience. This approach clearly creates a write-time inconvenience, but programmers over the lifetime of a system spend far more time reading code than writing code. This approach increases read-time convenience. By the time all the dust settles on a project, it might well also have improved write-time convenience.

Remember that names matter more to the reader of the code than to the writer Read code of your own that you haven't seen for at least six months and notice where you have to work to understand what the names mean. Resolve to change the practices that cause such confusion.

I appreciate everything that you have told me, but I don't know where this helps me. This is how my computer science teacher taught me how to code. I'm using Dr.Java and my code compiles but not everything works correctly. Can you tell me what is wrong with my code and why not all of my outputs are working correctly? Does my code make any kind of sense?

### #6 Dogstopper

Reputation: 2919
• Posts: 11,192
• Joined: 15-July 08

## Re: Golf ACSL Help

Posted 14 December 2009 - 09:56 PM

YES! THE GURU DELIVERS AGAIN! Nice one pbl!

### #7 pbl

• There is nothing you can't do with a JTable

Reputation: 8362
• Posts: 31,955
• Joined: 06-March 08

## Re: Golf ACSL Help

Posted 14 December 2009 - 10:04 PM

10rbacon, on 14 Dec, 2009 - 08:55 PM, said:

I appreciate everything that you have told me, but I don't know where this helps me. This is how my computer science teacher taught me how to code. I'm using Dr.Java and my code compiles but not everything works correctly. Can you tell me what is wrong with my code and why not all of my outputs are working correctly? Does my code make any kind of sense?

Appreciate you appreciated took me a while to type it
but I won't just try to decipher your code using variable names like A, B, C, D, p, q, r, s
We scan and reply to 10 to 20 posts here everynight, the less you can do is to have meningfull variable names imagine everybody named their variables A, B, C, D ....

Dogstopper, on 14 Dec, 2009 - 08:56 PM, said:

YES! THE GURU DELIVERS AGAIN! Nice one pbl!

Thanks
I recommend this Book to everybody

### #8 10rbacon

Reputation: 0
• Posts: 5
• Joined: 14-December 09

## Re: Golf ACSL Help

Posted 14 December 2009 - 10:10 PM

pbl, on 14 Dec, 2009 - 09:04 PM, said:

10rbacon, on 14 Dec, 2009 - 08:55 PM, said:

I appreciate everything that you have told me, but I don't know where this helps me. This is how my computer science teacher taught me how to code. I'm using Dr.Java and my code compiles but not everything works correctly. Can you tell me what is wrong with my code and why not all of my outputs are working correctly? Does my code make any kind of sense?

Appreciate you appreciated took me a while to type it
but I won't just try to decipher your code using variable names like A, B, C, D, p, q, r, s
We scan and reply to 10 to 20 posts here everynight, the less you can do is to have meningfull variable names imagine everybody named their variables A, B, C, D ....

Dogstopper, on 14 Dec, 2009 - 08:56 PM, said:

YES! THE GURU DELIVERS AGAIN! Nice one pbl!

Thanks
I recommend this Book to everybody

Well I blame my teacher because this is how she has taught me and my class. I am only a teenager in high school and I have only been programming for less than a half of a year. Is there any way you can tell me what a better variable name would be for say A and one for p? Take pity on me please!

### #9 pbl

• There is nothing you can't do with a JTable

Reputation: 8362
• Posts: 31,955
• Joined: 06-March 08

## Re: Golf ACSL Help

Posted 14 December 2009 - 10:24 PM

10rbacon, on 14 Dec, 2009 - 09:10 PM, said:

Well I blame my teacher because this is how she has taught me and my class. I am only a teenager in high school and I have only been programming for less than a half of a year. Is there any way you can tell me what a better variable name would be for say A and one for p? Take pity on me please!

I guess the text I posted should provide you with nice hints
What are A, B, C, D ? Number of par for every hole ? Number of beers you are allowed to drink after that hole ?
What are p, q, r, s ? just iteratrors ? OK I won't be fancy but why using 4 of them ?

That would o and be much clearer
```	for(int i = 0; i < 9; i++){
one += A[i];
two += B[i];
three += C[i];
four += D[i];
}

```

### #10 Jsb

Reputation: 0
• Posts: 1
• Joined: 20-December 09

## Re: Golf ACSL Help

Posted 20 December 2009 - 01:58 PM

Do you think that you could help me with the last section of this same code, here is how far i have gotten, i hope you find that my variable names make more sense.

```

import java.io.File;
import java.io.IOException;
import java.util.Scanner;

public class GolfingClient
{
public static void main(String[] args)  throws IOException
{
//file stuff
String pathToFile = "/Users/jeff/CS1- i love andrew/Golfing/";
File inFile = new File (pathToFile, "Golfing.txt");
Scanner dataIn = new Scanner(inFile);

int parValue, parTotal = 0, playerA, playerB, totalA = 0, totalB = 0, counter = 0, highScoreA, highScoreB, highScore, aHolesWon = 0, bHolesWon = 0;

for (int line = 1; line <= 9; line++)
{
parValue = dataIn.nextInt();
playerA = dataIn.nextInt();
playerB = dataIn.nextInt();

counter++;
parTotal += parValue;
totalA += playerA;
totalB += playerB;

if(playerA < playerB)
{
aHolesWon ++;
}
else
{
bHolesWon ++;
}
}
if(totalA < totalB)
{
System.out.println(totalA + " , " + totalB);
}
else
{
System.out.println(totalB + " , " + totalA);
}

highScoreA = parTotal - totalA;
highScoreB = parTotal - totalB;

if (highScoreA >= 0)
{
System.out.println(Math.abs(highScoreA) + " under par");
}
else
{
System.out.println(Math.abs(highScoreA) + " over par");
}

if (highScoreB < 0)
{
System.out.println(Math.abs(highScoreB) + " over par");
}
else
{
System.out.println(Math.abs(highScoreB) + " under par");
}

if(aHolesWon > bHolesWon)
{
System.out.println(aHolesWon);
}
else
{
System.out.println(bHolesWon);
}
}
}

```

#### Attached File(s)

This post has been edited by Jsb: 20 December 2009 - 02:05 PM