[ANU] [DCS] [COMP2100/2500] [Description] [Schedule] [Lectures] [Labs] [Homework] [Assignments] [COMP2500] [Assessment] [PSP] [Java] [Reading] [Help]

COMP2100/2500
Homework 8

Continue filling in a new Time Recording Log and Weekly Time Use Summary each week.

Write the following program, following the shiny new enhanced PSP as described in Lecture 19 and filling in the Project Plan Summary and a Defect Recording Log. Use one of the Project Plan Summary forms that doesn't have greyed-out sections. Remember to include a Code Review between the Code and Compile phases.

Before you start work on this program, go to the PSP Notes section below and prepare your personal Code Review Checklist for use in the Code Review phase.

Modify and extend your program from Homework 7 so that it writes money amounts in a way suitable for printing on a cheque.

For example:

comp2100@iwaki words 20.17
twenty dollars and seventeen cents--------------          $20.17
comp2100@iwaki words 200.00
two hundred dollars only------------------------         $200.00
comp2100@iwaki words .99
ninety-nine cents-------------------------------           $0.99
comp2100@iwaki words 2020.20
two thousand and twenty dollars and twenty cents        $2020.20
comp2100@iwaki words 1234567.89
one million, two hundred and thirty-four--------
thousand, five hundred and sixty-seven dollars--
and eighty-nine cents---------------------------     $1234567.89

Notice a few formatting features.

• The words are written in an area that is exactly 48 characters wide. Words are not hyphenated, so you will need to work out when a word won't fit, and move it to the next line. Lines that are not full should be padded out to the 48th character with dashes (minus signs).

• The amount is then written out in numbers on the rest of that last line, in such a way that the last digit of the cents part is the 64th character on that line.

• If there are no cents, write the word “only” instead of the number of cents. If there are no dollars, just write out the number of cents in words.

• If there are no dollars, you must still print a dollar sign and a zero before the decimal point when printing the amount as numbers.

The program should take its input from a single command-line argument, which must be of the form:

digit* '.' digit digit

In other words, zero or more digits, followed by a decimal point, followed by exactly two more digits. If the input does not satisfy this requirement, your program should print a usage message and exit.

---

Hints

Keep your tested integerAsWords() function from Homework 7 so that you can use it. You'll need to use it twice, once for the dollars and once for the cents.

If we were really going to do this properly, we would probably create a new class called Money (or something like that) and make this whole homework be essentially adding a feature writeAmountOnCheque() (or something like that). But don't worry about that for now: just write a program that reads an amount and prints it out correctly formatted.

I don't recommend that you read the input into a Real or Double. Instead do some string manipulation to break the argument into the part before and the part after the decimal point, then convert each of these to an integer. Watch out for the special case where the dollars string is empty.

For formatting the words part of the output, one strategy would be to first prepare the entire string, and then pass it to a new routine that cuts it into bits of the right length and pads them with minus signs.

---

PSP Notes

1. As with Homework 7, you will be re-using most of the code from last week, so you need to estimate and count the new and changed lines of code.

2. Since you will be adding a Code Review phase to your process, this is the time to prepare your own personal Code Review Checklist. (The following instructions are adapted from Chapter 14 of Introduction to the PSP.)

You will need your defect logs from all the programs you have written so far. Take a few minutes to read through them and make notes on anything that stands out.

The idea is to review your defect data to see which types have caused the most problems. Then you create a check list for code reviews so that you remember to check for the errors you know you have made in the past.

1. Make a table of all the defects that you have found in all the PSP programs you have written so far, broken down by type. (Next time you do this it will be necessary to break this down also by the phase in which the defect was removed — you'll be looking for those defects that you miss in your code review phase — but since you haven't been doing a code review so far, we need to look at all defects.)

   Here is an example, taken from my PSP homework a couple of years ago. I had written 6 programs: Lab 2 and Homeworks 3–7. I had a total of 23 defects in all.

   Type	Number
   10	1
   20	4
   30
   40	4
   50	3
   60
   70	1
   80	10
   90
   100
   Total	23

2. Rank the types in descending order of the number of defects found. In my example you can see that type 80 function defects account for almost half of my defects. So these are the ones I need to concentrate on. For you it will likely be different.

3. For the top few defect types, examine the defect logs in more detail to see what specific types of problems caused the most trouble. You might want to compile a list, perhaps trying to further break them down into groups that are more specific than the simple classification we've been using.

4. For defects resulting from these most important problems, work out in your group what steps you would need to take in a code review to find them.

   For example, suppose you make a lot of type 40 assignment defects that turn out to be caused by forgetting to declare local variables. Then you might find it very helpful to check every variable you use in your code to make sure that it has been properly declared.

   Or if (like me) you often forget to increment a loop counter, it could save a lot of time to check every loop to make sure that the counter has been incremented. (Or perhaps you could add to the coding standard that every loop must have a loop variant.)

5. Add items to your code review check list to make sure that you follow these steps every time you review your own code.

6. Think also about the general code review instructions and advice from Lecture 14, and add items to the check list so that you make sure you do a thorough check of your code. Your aim is to remove all defects in the Code Review phase, so that there are none left in Compile and Test. This is an extremely difficult, if not impossible, goal to attain, but you want to get as close as possible.

   Some items you might want on your check list:

   • Check that the code is complete, that everything in the design has been coded.

   • Check every line of code for correct syntax.

   • Check that parentheses, brackets and braces balance.

   • Check that the code fulfils the requirements. (This is much harder than criticising style.)

   • Check for robustness: will the program crash if the input doesn't conform to expectations?

   • Does the code conform to a coding standard? (We haven't talked about coding standards yet, but I think you were given one in COMP1110. If not, there is one on the Sun website that you should look at.) The next few items here address this at least in part:

   • Are identifiers appropriate? Function and field names should be nouns, procedure names should be imperative verbs and boolean function or attribute names should be true/false statements or adjectives.

   • Check for unhelpful or misleading identifiers.

   • Check for inappropriate uses of manifest constants.

   • Check for missing, useless, incorrect or misleading Javadoc comments.

   • Check for too many, too few, confusing or incorrect ordinary comments.

   • Check for missing, incorrect or useless assertions (require, ensure, loop invariant etc).

   • Check for incorrect indentation.

   • Check for routine bodies that are too long or too deeply indented.

   • Check for confusing structure.

After you have used the checklist a few times, review the new defect data the same way (counting only those defects found in Compile and Test, that is after the Code Review phase). If the checklist was effective at finding these defects, you could start looking at the new most frequent type of defect and add an item to address that. If the checklist was not effective, you may need to modify it so that it works better at removing your most common defects. If some of the items in your check list are not finding any defects, then you might want to consider merging them to save time, or even deleting them. Perhaps you no longer make those mistakes.

How to use a code review checklist

Your finished code review checklist should look something like this:

Description	Program #7	To Date	To Date %
Check that each variable used is correctly declared	X	3	20%
Check that everything in the design has been coded	1	5	33%
Check that all parentheses balance	X
Check that all loop counters are incremented	2	7	47%
...

As you work through the check list, put an ‘X’ if you didn't find anything, or the number of defects found if you did. Keep track of the number of defects found by each item in the checklist; the ‘To Date’ number should be the number found on this sheet plus the ‘To Date’ number from the previous one. This will help you to see which items on the checklist are most effective.

[ANU] [DCS] [COMP2100/2500] [Description] [Schedule] [Lectures] [Labs] [Homework] [Assignments] [COMP2500] [Assessment] [PSP] [Java] [Reading] [Help]