Overview

In this programming project you will implement a simulation of a bank account ledger, accounting for deposits, withdrawals, paychecks, and interest. This will exercise and build on the skills you have learned so far about variables, if statements, loops, and file input, as well as program design, style, and documentation.

The project is broken down in to parts which progressively add more and more functionality, with more possible points. Each part has its own test cases online.

Tips for success

Here are a few tips that have been helpful for previous students in this class:

• Start early! Because programming is such a creative progress, it’s notoriously difficult to predict how long ANY programming project will take you to complete. If you start early, the worst that can happen is you finish early and get to relax.
• Work deliberately, stopping frequently to recompile and test what you have so far. This is the best way to catch problems early and easily.
• Start small. Don’t go for the big example right away. Instead, use a smaller debugging example that you can follow completely, so that you can check your work.
• Re-submit frequently, and definitely when you finish each part.
• Writing good documentation, variable names, etc., as you go along is always easier than trying to add it in at the end.

Grading

70% of your grade will be based on functionality (does your program work as specified), mostly based on the test cases that you see when you submit, but perhaps also extra test cases according to the specifications of the project. The code you submit must work if you expect to earn a passing grade.

30% of your grade will be based on coding style, which includes:

• Readability: You should use good spacing and proper indentation, and avoid long lines longer than 80 characters.
• Documentation: Use meaningful variable names and write helpful comments to make it obvious what your code is doing.
• Organization: Use your tools wisely! Don’t have unnecessary conditions or loops. This is about the “art” of programming, beyond just “getting it to work”.

All of this is factored into your maximum score based on which part you have completed. So for example, if you complete up to part 3 perfectly working and also get 25/30 on style, then your final grade would be \((70 + 25) * .85 = 80.75\), a B-.

Honor Policy Reminder

Be sure to review the course policy on collaboration for programming projects, which are more about the work you can do on your own and have different rules compared to homeworks and labs. In particular:

• The only help you may receive on a project is from your instructor MGSP leaders for this class, and that help must be clearly cited. In turn, you cannot provide help to any other students on this project.
• In no circumstance - project, homework or lab - may you copy code and submit it as your own work. That is the definition of plagiarism.
• For projects, you may not look at other people’s project code nor may you show your own code to others.
• You can look at online resources for general purpose C programming, but not for help writing financial simulations or anything else that is specific to the functionality required of your project.

If you have questions about any of these rules, email your instructor and ask about it. We know you want to do what’s right and we are here to help you!

Files

For all parts, the program you submit should be in a file called ledger.c. It is strongly advised that you save a backup of your ledger.c program as you complete each part and get it working.

There are a number of example files that you can download in this tarball. To extract the tarball, copy it to your project folder and run the command tar xzvf ex.tgz, which will create a subdirectory ex/ in your project folder which has all of the example transaction files referred to on this page.

Part 1: One deposit per day (up to 30 points)

For this part, your program will simulate a series of days, adding a deposit to the bank account each day, and reporting the final balance as well as the average end-of-day balance at the end.

Your program will start by reading a line “run <FILENAME>” from the terminal, where FILENAME is the name of the file that has the daily transactions.

The transactions file starts with a line like “<N> days”, followed by \(N\) lists of transactions. Each transaction, in this part, will be a deposit, formatted as “D <amount>”. Each day’s transactions end with a line that just has ENDOFDAY. For this part, you may assume that there is only one transaction per day.

For example, here is the file p1a.txt that is included in the tarball you downloaded and extracted into your ex/ directory:

4 days
D 50
ENDOFDAY
D 1.50
ENDOFDAY
D 48.50
ENDOFDAY
D 25
ENDOFDAY

You can see that each day has a single deposit with a different amount. Starting with a balance of zero, the balance after day 1 is 50, after day 2 it’s 51.50, after day 3 it’s 100, and after day 4 it’s 125. Therefore the final balance is 125 and the average daily balance is

\[\frac{50 + 51.50 + 100 + 125}{4},\]

which equals 81.625. You can see these values correctly reported in the first sample run below:

roche@ubuntu$ ./ledger
run ex/p1a.txt
Simulated 4 days.
Final balance: 125
Average end-of-day balance: 81.625

roche@ubuntu$ ./ledger
run ex/p1b.txt
Simulated 100 days.
Final balance: 5183.85
Average end-of-day balance: 2566.28

While you can always assume that the transactions file is properly formatted, you should handle two kinds of errors in the input line from the terminal:

• If the user enters an initial command that is not the word run, print an error message like Invalid command: <command> and exit with status 1. For example:

  roche@ubuntu$ ./ledger
  go ex/p1a.txt
  Invalid command: go
  [Exit 1 ]

  (Note: the last like [Exit 1 ] isn’t actually output from your program, but shows up from the prompt if you return 1 from your main in C.)

• If the user enters “run” as the command, but the filename they give can’t be opened, print an error message like File "<filename>" not found and exit with status 2. For example:

  roche@ubuntu$ ./ledger
  run notafile.txt
  File "notafile.txt" not found!
  [Exit 2 ]

Part 2: Multiple transactions per day (up to 60 points)

(Don’t start this part until your part 1 works perfectly! And once it does, it’s probably a good idea to make a copy of the file before you start on the next part.)

Now you will extend your ledger program to so that the transactions file can have multiple deposits or withdrawals per day. The format of the file is the same as before, with withdrawals indicated by a line W <amount>. Here is the small.txt file that’s part of the tarball you extracted and downloaded into your project directory:

5 days
D 50
W 10
ENDOFDAY
W 400
D 200
ENDOFDAY
ENDOFDAY
W 1
W 1
W 1
ENDOFDAY
D 1.50
ENDOFDAY

Notice that every day might have a different number of deposits or withdrawals, even none at all (as in day 3 in the example file above). Also because there can be withdrawals, you can have a negative account balance.

The output from your program should be the same as before, reporting the final balance and the average end-of-day balance. For the example above, the ending balances on each day are 40, -160, -160, -163, and -161.50. So the average ending balance is what you see in the first example run below:

roche@ubuntu$ ./ledger
run ex/small.txt
Simulated 5 days.
Final balance: -161.5
Average end-of-day balance: -120.9

roche@ubuntu$ ./ledger
run ex/med.txt
Simulated 20 days.
Final balance: 290.53
Average end-of-day balance: 82.1745

roche@ubuntu$ ./ledger
run ex/big.txt
Simulated 89 days.
Final balance: -893.98
Average end-of-day balance: -193.959

Note that all of the examples from part 1 should still work, including the error conditions.

Part 3: Initial balance and paychecks (up to 85 points)

(Again, be sure to submit and get the previous parts working completely before you start on this part.)

You will now add two new functionalities to your program. The user can specify an initial balance (which is zero by default) for the account, and a paycheck amount (which is also zero by default).

The rules with the paycheck are as follows:

• The simulation starts on a Monday.
• The paycheck amount is deposited every other Friday, starting with the first Friday.

The user may specify an initial balance and/or paycheck amount by giving the commands “initbal = <amount>” or “paycheck = <amount>” before the run command. Here are a few example runs:

roche@ubuntu$ ./ledger
paycheck = 1000
run ex/small.txt
Simulated 5 days.
Final balance: 838.5
Average end-of-day balance: 79.1

roche@ubuntu$ ./ledger
initbal = 500
paycheck = 250
run ex/med.txt
Simulated 20 days.
Final balance: 1290.53
Average end-of-day balance: 807.174

roche@ubuntu$ ./ledger
paycheck = 405.31
initbal = 150
run ex/big.txt
Simulated 89 days.
Final balance: 2093.19
Average end-of-day balance: 1326.81

Here is a detailed breakdown of how the second example above works, with an initial balance of 500, paycheck of 250, and the med.txt example from the tarball.

Day	Transactions	Paycheck	Ending balance
(initial)			500
Monday			500
Tuesday	-61.68		438.32
Wednesday	+32.71 +28.44		499.47
Thursday	+96.77 -27.6		568.64
Friday		250	818.64
Saturday			818.64
Sunday	-46.45 -4.04		768.15
Monday	+42.64 +23.9		834.69
Tuesday			834.69
Wednesday	-42.85 -80.76		711.08
Thursday	+13.04		724.12
Friday			724.12
Saturday	+83.16		807.28
Sunday			807.28
Monday	+78.78 -23.42		862.64
Tuesday	+90.39		953.03
Wednesday	+24.36		977.39
Thursday			977.39
Friday		250	1227.39
Saturday	+63.14		1290.53

Again, remember that everything from the previous parts should still work. This includes the error conditions. Be careful about the error condition for an “Invalid command”, as this now has to account for the possibilities of setting initbal and/or paycheck before issuing the run command.

Part 4: Interest (up to 100 points)

Any good bank wouldn’t just let money sit around and do nothing. Instead, they give you extra money in the form of interest when you have a positive balance. If you have a negative balance, that’s considered a loan and they charge you extra money at a much higher rate.

For this part, your program will allow these two rates saverate and loanrate to be set by the user in a similar manner to initbal and paycheck as in the previous part.

The rules for computing the interest are as follows. Read carefully!

• The interest is calculated at the beginning of each day, before the day’s transactions and any paychecks are added.

• Whenever the current balance is positive, then the interest added is calculated as

  current_balance * (saverate / 100)

  If the current balance is negative, then the interest charged is calculated as

  current_balance * (loanrate / 100)

  (which will be a negative number also, so it gets charged and not added to the account.)

  Note: Dividing by 100 is to turn the percentage into a decimal.

  Nore also: If you wanted to be more accurate to real-life, we would enter the rates as annual interest rates and then divide by 365 to get the daily compounding interest rate. But we won’t do that here.

• Interest payments or charges are not added to the balance immediately. Instead, they accrue in a separate “side account” that is added every 30 days to the account.

• If you consider the first day to be “day 1”, then the interest for day 1 up to and including day 30 is all added (or charged) to the account balance on day 30. Then a new amount starts to accrue on day 31, and so on forever.

• Unless your simulation ends exactly on day 30, 60, 90, etc., there will be some interest left over in the “side account” at the end. That’s fine; don’t add it to the final balance or anything else.

Of course, if a saverate or loanrate is not specified, it defaults to zero.

Here are a few example runs. You probably want to work out some additional test cases on your own!

roche@ubuntu$ ./ledger
saverate = 1.5
loanrate = 5.5
run ex/big.txt
Simulated 89 days.
Final balance: -1142.24
Average end-of-day balance: -264.382

roche@ubuntu$ ./ledger
saverate = 9.0
run ex/big.txt
Simulated 89 days.
Final balance: 260.957
Average end-of-day balance: 352.589

roche@ubuntu$ ./ledger
initbal = 100
paycheck = 800
saverate = 6.0
run ex/big.txt
Simulated 89 days.
Final balance: 15501.2
Average end-of-day balance: 6950.61