The first iteration of our class project went much smoother than I had anticipated. Unlike many of the projects and assignments that I've received from other, similar CSci classes, this one seemed to provide much more direction and guidance. But unlike many of my other assignments, this one seemed so very monotonous in its coding. It seems like over half of the time I spent on this project was spent determining what regular expression would encapsulate that one-word keyword or character. Possibly the only interesting regular expression that actually required my full attention was the string constant.
The problem was that there was too much to copy from. I don't think there was a single piece of code I wrote that I didn't (conceptually) copy from one of the previous labs.
- Consume_WhiteSpace_and_Comments?
- all of the regular expressions. . .
- Looping through the text and using integers to determine the longest match.
- the entire token enum type was pre-created.
But I should be careful about what I say, lest I jinx it the next iteration becomes more difficult.
So instead I'll talk about the development process my partner and I went through, and what about that worked well.
The way we worked on this first iteration was to construct much of the scan() method, and write half of the regular expressions first. This wasn't difficult as most of the expressions we wrote were for keywords, so they all followed the same structure. Next we wrote a few test cases that would verify these keywords by themselves would be recognized by the scan() method. After a few tweaks and typos, we finally had a working scan that could recognize basic keywords.
Next we constructed more regular expressions, and this included some of the more advanced ones, including integers, floats, and variable names. We skipped string constants since we didn't know how to handle them at first. Following this, we wrote more tests to verify our integers/floats/variable names all registered.
And we rinse/repeated this process until all of the regular expressions were accounted for. Once we had them all working (including, by this time, the string constants) we unlocked the instructor-made test cases and debugged them until each one ran without any errors.
Working in pairs for this first iteration wasn't as bad as I had anticipated. I was worried we would have a lot of SVN collisions, and to my surprise, we had none. I guess we were never working on code at the same time, which is fortunate - hopefully we can keep that up. I still think working in pairs was completely unnecessary, and in fact I would have preferred working alone instead, but that has mostly to do with my personality. I just prefer working alone. But I understand the principle of requiring us to work in pairs - it's more real-world applicable.
For the next iteration, I think we'll probably be switching up the SVN blame counter, as for the first iteration it was heavily in my favor (I anticipate, I didn't actually check). But this harks back to what I was saying at the beginning. I coded most of the scan() function (possibly all? if not then close to), but since most of that was a copy/paste of itself (for EVERY regular expression, and a large chunk of the loop), put into perspective, I didn't really code qualitatively any better than my partner, who did a large majority of the testing.
On that note, in regards to what was said in class last Thursday, about how we should test the pieces of code that we write, I strongly disagree. I've learned (and experienced) that if you test your own code, you tend to only test the cases you expect as input. But good testing should also expect the occasional corner cases. In general, the less you know about the code, the easier it is to imagine a good variety of test cases to throw at it.
Anywho, this'll wrap up my thoughts for the first writing assignment. In short, everything went better than I expected, and I certainly hope that continues in future iterations!
Leave a comment