Putting it together: an inventory report

The shape of the program

This program keeps a small inventory. Each item is a record with a name, a price and a quantity. The items live in one array, and a single loop fills in their fields, works out each line total and adds it to a running sum.

The report is printed from inside the same loop, so the totals and the lines on screen can never disagree — there is only one pass over the data.

The record is the unit of data, the array is the collection, and the loop is the only place that touches both. Keeping those roles separate is what makes the program easy to extend: a new field belongs in the record, a new item belongs in the array, and the loop rarely changes at all.

Where the chapters land

The record type is the records chapter, and the list of names is a constant array from the constants chapter. The array of records and the low … high loop come from the arrays chapter.

The running total is the loops chapter, the line total is arithmetic, the branch-free report is writeln matching types as in the values chapter, and the case of a missing item would be a case or an if from earlier still.

Nothing here is new. A capstone is the earlier pieces working in one file, which is exactly what a real program is.

What a real one adds

Real inventory software reads its rows from a file or a database, sorts them by name, and keeps money in whole cents so that rounding never drifts. It also checks for items whose quantity is zero and prints a warning.

Those are additions to the same shape, not replacements for it. Once the record and the array are in place, a sort is a loop and a comparison, and a warning is one if inside the report loop.

This page has no keyboard input and no files, so the data is generated inside the program. The reader exercise is to add a fourth item by hand and watch every total follow.

The same shape survives those additions because nothing in it depends on the data being hard-coded. A file or a database simply fills the array before the loop starts; a sort reorders it between filling and reporting. The report loop does not care where the rows came from.

Columns without counting spaces

program Main;
begin
  writeln('Name':8, 'Qty':5, 'Total':7);
  writeln('Pen':8, 3:5, 30:7);
  writeln('Pad':8, 2:5, 40:7);
end.

One pass, three jobs

The capstone separates three jobs inside a single pass: fill the record, compute the line total, and fold that total into the grand sum. Doing them together is safe because each item is touched once, in a known order, and the running sum is always the sum of the lines already printed.

The alternative, one loop to print and another to total, is also correct but gives the two loops a chance to disagree. If anything changes the array between passes, a report whose total does not match its lines is worse than one that is merely slow. The same argument is why the first example computes its line total once into a variable rather than twice in the print call.

A worked pass over the data

Suppose the loop is on its second pass, with i equal to 2. It copies the name Names[2] into the record, sets a price and a quantity, then multiplies them into line. It prints the name, the quantity and the line total, and adds line to total. The third pass repeats the same steps with i equal to 3, and after the loop total holds the sum of every line.

Reading one pass at a time is how you check a report without running it. Ask what i is, which record that addresses, what line holds afterwards, and what total held before. If any of those four answers is unclear, the loop is doing more than you can verify, and splitting it is the fix.

Try these next

• Add a fourth item and change every bound that has to agree with it.
• Print a low-stock warning for any item whose quantity is below two.
• Move the line total into a function and call it from both the report and the grand total.