davewhiteland
commented
4 months ago Aux motive power is optional — the default is none and the text does say "You don't need a backup". Also, worth noting that if a student does add an incorrect rule enforcing an aux power, nothing specifically breaks (although you might be spending more on your buggy than you strictly needed to).
Not tabulating the rules is a deliberate design decision (and maybe it's wrong): the rules, unlike the other specs, are not tabulated. I mention this on the "Design principles" page of the docs :
The buggy racing specification is deliberately large, and the rules embedded in it are not all tabulated or enumerated. At some point every student needs to find where the boundary between specification and implementation lies in the software they write. When is data encapsulated in code? When is it explicitly separate?
I want students to have to figure out the rules. I think of it as a reading comprehension task which is really part of the "understanding the problem domain" problem that I am OK about forcing students to have to dive into, and think about. (That doesn't excuse ambiguity in the text of course — although in the case of aux power, I don't think it is ambiguous but could be persuaded: might be helpful to add optional... but then that's true of all items (not just aux_power_type) that have a default value of none, so I am not yet convinced).
This matters for task 2-RULES so if you want to enumerate them for your students, you could tabulate them and and add that to the task text in the Hints section
At the moment it is not clear to students what the race rules are in the /specs page unless we tell them to look for bold text/the word "must". It would be helpful to have another column called "rule" or "constraint" which holds this info. For example:
Also, I am unsure if "Auxiliary motive power" has a rule where you require a backup or not? Wording is slightly confusing. Adding the rule column above would probably help clarify.