It’s hard to believe that next week we finish our first semester in the MIS program. It’s been tough, but we have risen to the challenge. Although CS120 is not meeting in class this week, we have one more programming assignment due before our final exam. PA7/8 was a challenge for many of us because it challenged us in a very unexpected way. PA9/10 (this week’s assignment) builds on that lesson. Both programs start with two files: master.txt (a list of records sorted by salesperson id numbers) and trans.txt (a list of transactions to be performed on the records in master.txt). The program reads a code from trans.txt, interprets the code, and either performs the transaction or records an error. If the code is a 100 the program reads in a full record from trans.txt and adds it to newMaster.txt. If the code is a 101 the program reads the salesperson id (SPID) and “deletes” the corresponding record from the new master file (simply by not sending the record from master.txt to newMaster.txt). If the file calls for a record to be added that already exists or to delete a record that doesn’t exist in master.txt, the program writes an error message in errorLog.txt.
PA9/10 builds off 7/8 by added several possible transactions (and thus more possible errors). Codes 102-108 are modify in part codes. 102 modifies just the second field of the record; 103 modifies the third field, and so on up to code 108 and the eighth field. Transaction code 110 is a modify multiple code, or what I call a replacement code. 110 is followed by a complete record that needs to replace an existing record (so one thing could change, or everything except the SPID could change). And finally 111 is a print code that prints the record to the console before adding it into the new master file.
It seems pretty simple though right? Just reading and writing to different files. Both the master file and the transaction file are sorted by ascending SPID and the new master file must be constructed in a way that preserves this organization. Based on what we have learned through-out the semester, our first instinct was to read the records into an array, perform the transactions, and then use a sort function to clean it up before writing it to newMaster.txt. Hooper said no. Hooper said no arrays were to be used and no sort functions were needed. Many of us had no idea how to approach the problem without using an array.
The answer is quite simple really. Using an array is way too complicated for this program. We were choosing to over-complicate a problem just so we could use the approach we were most comfortable with. Probably the biggest lesson to be learned from these assignments is a reminder to not make extra work for ourselves. It is time consuming, more complicated than necessary, and keeps us stuck in the rut of using what we are familiar with rather than actually thinking through a problem and evaluating all the options.
I’m not sure about anyone else’s PA9/10, but I have just finished the program. I was describing it to someone as a crazy 385 lines of nightmarish nested if/else statements that reads from two files, writes to two files, contains a struct, and overloads both the input and output operators. I’ve been spending some time testing it against all kinds of data to make sure I haven’t missed anything. I have a confession to make. The biggest lesson I have learned from this headache of curly braces is this: plan through coding carefully to prevent redundancy. Loops were absolutely necessary in this program, but while I sit here and look at my work, I can spot about fifty lines of code that could have been eliminated if only I had handled it more efficiently. So my new challenge is to see how many lines I can consolidate while maintaining a working program and keeping the code easy to understand and use for others.
This semester has been a whirlwind of challenge and learning, but we have persevered. I look forward to the next challenge. See you all soon!