Slog Entry Week 4

I liked this exercise because it was really math-heavy, and I like geometry. I hard coded separate classes for each shape, which worked on the first-time through, even before I was running any static analysis. I do all my coding in PyCharm now, back then I was using IDLE. I was forced away from IDLE because it would occasionally throw random syntax errors on completely syntax error free strings (I ran the same code in PyCharm and it was fine). I think it was having trouble distinguishing between opening and closing quotations, even though there was no difference in visual representation in the editor, or in key on the keyboard. Anyway, I couldn't figure out how to fix it, so I switched to PyCharm.

It was only after submitting that I chanced to glimpse my friend's code for the same exercise during a Settlers of Catan based social gathering. The __str__ method had a lot of if/else control flow that checked for angle = 90 and base = width to determine the type of quadrilateral. I thought that was pretty slick. Although it was less readable (IMO) due to a lot of indentation levels and long blocks of code, it probably accomplished the same goal with less duplicate code, which is respectable. It really got me thinking about how to write code with the least duplication, in one line if possible.

In the lab, my partner and I were slowed down by the unit testing step. We didn't really know how it worked, so we expected a lot more automation than is reasonably possible. I think our first attempt was to put "unittest" at the end of our code, and expect it to figure out what we wanted our code to do, and if it did that. Pretty optimistic.

We got the tests working once we understand that each test works by basically asserting that some statement is true. I was proud to be able to tell my dad that we learned unit testing in Computer Science. He's a programmer, and he works in QA, so the vast majority of his job is running unit tests and enforcing unit testing standards. It was this week that he started drilling into my head that you should write unit tests for your code as you write your code, because you can avoid a lot of problems that way, and detect bad code before you pack it up and ship it off to QA. I didn't really get it until I stayed up until 4:00 one night/morning trying to get my three stools algorithm to work. More on that later.