Session Recap: Sunday, September 26

Attendees were Steve, Adnan, Jordan and Sam.

[This entry was written by Sam after an extremely busy week; many details have been lost to the vagaries of CRS*.]

After a brief planning session (in which, after some discussion, we left the order unchanged), we paired up and got to coding. Jordan and Adnan took the Automatic Backup story, coming up with a solution in which all module texts across multiple backups would be appended to a single XML document, and could be backed up and restored using a not-yet-written interface. Steve and I worked with Context Parameters, paying down some of the refactoring debt on clsVBModuleLineReader and its tests.

After lunch, we came back and discussed the Auto Backup feature. The point was raised that if our software caused a situation requiring modules to be restored from a backup, anyone using it might not be too inclined to trust our interface to do the restoring. With that and other points in mind, we came up with a different scheme, where a backup folder would be created with a date/time stamp embedded in the folder name, and all modules would be saved to individual textfiles in that folder, so that they could be manually copied and pasted back into the IDE as needed. (As a bonus, this mechanism also allows us to use a diff tool for integration.) Adnan and I worked on this new scheme while Steve and Jordan kept working on Context Parameters (since Steve had a clever idea for it that I'd forgotten over lunch).

Adnan and I re-completed the Auto Backup story and moved on to the Basic Standard Error Macros story, since everyone but me had already worked on it and we thought a fresh pair of eyes might be able to pretty it up somewhat. This did not happen. In order to allow for users to include custom code everywhere it might be needed, we need no less than five separate macros per procedure. The resulting metacode tags make a procedure virtually unreadable. (As Steve said, it's a good thing that the point of this exercise is to learn XP first and produce good software second.)

Design Digression: On that topic, I had two ideas that might help. The first is this: change the expansion syntax for macros with only one body line so that the expansion fits on one line (e.g., "    Debug.Print "foo"    'print foo    '/<Macro lines="1" />" or similar). This would require some additional logic to recognize this as a metacode section, but could be done. I'm not sure how optimal this would be in terms of procedure readability, but it's better than what we have now. The second idea was to implement user-customizable sections that would be ignored during re-expansion. Especially if we moved the tag for such sections over from the left margin, this would actually make it extremely clear where the user should write code, and visually reinforce the concept of a try/finally/catch (in VB order) block. It might look somewhat strange for basically the entire procedure to be inside custom sections in a single macro, but even if it's not a net reduction in the number of commented lines, this might make the overall effect of those lines much less jarring. Perhaps it's worth a mockup of what a procedure might look like under such a scheme before coding that feature?

Anyway, having quickly come to the conclusion that Basic Standard Error Macros were about as good as they were going to be given the available features, Adnan and I moved on to Friendly Error Reporting and made some small progress on that before we called it a day and integrated.