t-peterl@microsoft.UUCP (Peter Labon) (03/30/88)
I still haven't seen mention of grading on speed/size of code. This is a real concern everywhere I've worked, but not many schools seem to teach it. I've been explicitly graded on speed/size in at least one course, and this taught us (the class) how not to waste data space (a.k.a. why a 100 by 100 matrix need not occupy 10,000 bytes (or words!) if it is sparse (sounds trivial, but ...)) and speed (recursion might be cute but heuristics can be better), and code size (seems to have the effect on some people of not GOTOing everywhere, and actually using functions,while/for/do constructs,etc.) Also there is a need for more group software projects. I remember one where a partner of mine (not by my choice (or the choice of the other two members)) didn't want to start designing/coding until I was done, because he didn't believe me when I told him ".. if you call routine X with parameters Y it will do Z and return A". I guess he believed a four-man project meant each member of the group worked for a quarter of the semester in a sequential manner. Another part of the 4-man project was grading the design/implementation document of a different team, and we were graded on the grading (recursion, eh). This meant being tough, but fair, and not slack or nasty. I read somewhere in this news group about modifying someone elses code as part of a CS course. Good idea! Give them both a really bad piece of spaghetti code, and some well structured code, so that students can see that it is possible to write good code. An advantage of co-op education is that not only you get to see in practice, what you learned in theory, but also to re-evaluate practice in the light of more theory (by going back and forth between work and school 6 times). --Peter Comp Eng - the choice of a new generation Need for speed = strain on the brain Disclaimer: The above thoughts are the sole product of my brain and the caffeine it runs on.