Week 4 (9/17-9/23) - Source Code Organization

Definitely had a rough week. It was interesting to learn about the way exceptions are handled in C++. It still seems like the Java way of dealing with exceptions is a little bit better. If you're going to go through all the trouble of inventing a system that could cause your program to halt if used incorrectly, at least in Java, the use of Checked Exceptions requires you to tell someone about it. In C++ if you miss catching an exception that you didn't know about, your program halts/crashes and there's nothing you can do about that once it's in production except to track down the cause of the problem.

I still haven't quite gotten a handle on the daily quizzes. I forgot to do the reading but for some reason I had convinced myself that the quiz over the reading wouldn't be until Monday morning. I definitely won't be making that mistake again. Luckily there are dropped quizzes to make up for the "duh" moments like this.

The quiz mentioned the canonical way to build classes in C++. However, beyond mentioning the canonical class methods, we didn't go into a whole lot of depth, although I wish we had. So, I went and looked up an article that would tell me a bit more (http://www.cplusplus.com/articles/y8hv0pDG/). It's nice to see a write up but I hope that we still visit these topics in more detail during the lectures.

Project 2

The project was going pretty well until Saturday. About 9 pair-programming hours into the project and we thought we had the problem solved. Then we submitted to UVa and got a Runtime Error. We figure something went wonky with our assertions. Maybe a first troubleshooting technique would be to comment out all the assertions and see where that gets us. We definitely need to do more acceptance testing. Perhaps "random" inputs will help us discover the Runtime Error on our end. We definitely plan to take advantage of the public tests repo to help us figure out this problem.

Source Code Organization

Something that still feels wrong about the structure of the projects is that the executable code is being written in a giant header file. Now I know this isn't the software engineering class, but shouldn't we be paying a little more attention to good coding style?

I mean, a good way of handling a submission would be to let us turn in whatever source files we want for the actual submission, and provide a Makefile that will generate the required executable that they will use for testing. Makefiles aren't all that hard, but we could even be provided with a template Makefile and given instructions on how to use it. Considering that the class is already having us learn Git, it would make sense to have us learn Makefiles as well, which is another, more ubiquitous, and equally useful technology.

Anyway since my partner, Tri, and I wanted to be a little more organized, we made our class definitions in separate header files which we include in the Voting.h file.

We will have to remember to move those definitions directly into our source file before submitting our project.