Writer's note- It seems like every time I sit down to write something, it always starts out (and often ends up) very technical and composed; to break away from that for this entry, I think bullet points will help.
Without any particular introduction or formalization, here are my musings on Iteration 1:
- Test-driven development: I am now a definite fan of test-driven development. I've had my own projects in the past get horribly bogged down from all of the hazards that test-driven development subverts, and creating the test cases first was extremely helpful in the overall design process. There was hardly any need to formalize any design work on this small of scale of a project; after identifying the components of the scanner and their dependencies (e.g., tokenizing depends on consuming whitespace/comments and creating proper regular expressions), writing the test cases for what the code was to do was totally indicative of how to write the code. Plus, it made sure we didn't screw anything up or make any oversights.
- Subversion: Also a great tool, although not one that I haven't used before. It wasn't necessarily useful in this iteration, given that my partner and I did almost all of our coding together and often on one workstation, but subversion scales very well, and I could foresee the desire to revert to past revisions if things go wrong, at least in other, larger projects (I actually stopped work on coding a game halfway through not long ago after making too many untracked changes). I was pleased at the ease of submitting assignments with the repository in place, rather than compressing and submitting all of the files or having them examined in person for each lab assignment and iteration.
- Python and makefiles: I would like to see a bit more coverage of scripting and makefiles in the future, and I will probably look into Python a bit myself. Our tagit script ending up only copying one particular revision regardless of what revision number was most recent, which was difficult to address having worked with little more than copied-and-pasted base code taught in lab. I also never felt as though I understood how cxxtest works. The makefiles went a fair amount better, given that I had some experience with makefiles from Operating Systems, and once they worked, they were extraordinarily convenient, abstracting away any thought or effort that would be put into compiling the individual files as they were edited or trying to run the tests individually. This seems from the auxiliary reading to be of necessity: making the test cases simple to run so that they are run with great frequency.
- Formatting: I'm still uncertain about how to approach formatting when receiving code from someone else to implement without any further feedback (i.e., the professor gives us the code and we give nothing back until it's done). My partner and I hadn't decided on formatting until mid-way through the coding, by which point we had already mixed in tabs, parentheses without spaces between them, and marginally but noticeably different naming conventions into the original code, which convoluted the formatting. This was despite our agreement on the emulated pure blocks style; there turned out to be a lot more formatting considerations to be made than just that. We ended up skimming through all of the code at the end for consistency, with a lot of find-replace operations for tabs vs. spaces, etc., which often carry their own unwanted side-effects. On top of that, after we had settled on the formatting style, the files received for Iteration 2 had a handful of changes in their formatting, such as (some of) the file names being capitalized. This brings back the original point: Do we just stick with what we're given, or do we go through every file for consistent formatting?
- Other impressions:
- I got a fair amount better at remotely accessing the Linux labs after having to rush to rename some files so the grading bot would recognize them.
- I still dislike Emacs for its cumbersome lack of convenient copy and paste operations.
- Naming conventions on our test cases for Iteration 2 might need some more adjustment. I hesitate to consider it heinous that we ended up just numbering our test cases instead of giving more accurate names (e.g., test_good_regexes_keyword_1 vs. test_good_regexes_keyword_main), although it's been discussed that interpreting the results of the tests should take no effort, and with such a numbering system we would need to (slightly) more thoroughly examine the output. We also didn't test every single regular expression and its tokenization, and although we also didn't have any problem with the regular expressions that went untested, I know I'm being a tad hypocritical given my earlier acclaim of test-driven development and the like.
- Fun fact: In England, adding "-ize" or -"ation" to the end of a word is generally laughable, as in "tokenization."