Quote:
|
Originally Posted by ewankoff
The re-implementing of the code forces students to figure out how to make that specific code work with this years robot.
|
I am not a programmer and I am not responding directly to the rule itself. I want to suggest a different way to think about this, but I hope I'm not off the mark with this opinion.
Some, if not all, teams document their code development like any other engineering project, including everything from the problem statement to reasons for choosing certain solutions to a description of the final product. If you're documenting a program, you would explain why each detail of the code was written the way it was, and why it solves the problems of this year's game and this year's robot. You haven't done a good job with your documentation if you say, "This code has worked before..." or "This code worked on last year's robot/another robot...so we decided to use that code for this year's robot."
Even if you would use your code from a previous year, or if you would use someone else's code, it is much better--
and common practice--to explain the details of that code, show why each one is appropriate for your needs and goals, and show why you chose this code instead of writing your own. (Also acknowledge it when your code isn't original, even if you think that would affect a score.)
Would anyone have any objections to copied and pasted code if the team members can thoroughly explain why the code has been written in the way that's right for this year's robot?