The problem's quite common, having been a TA for a few lower level university programming classes, and graded the things. I think it comes down to force of habit. Although we're told a million times to code on paper first, and on a machine later, hardly anyone does, because an editor is as good a tool as any to layout structure and flow of control through function definitions and user defined types. The habit backfires when it comes to using paper. The way I'd recommend to tackle such exam questions, is to start off with a bunch of scratch paper and draw the bigger picture. Then refine bits and pieces, filling in functions, formalizing parameters, and so on. Finally bring it all together. Then when you write the code, you're working off a solid draft. I realize that this is time consuming and seems contrary to the time restricted nature of exams, but it's likely that once you do put down the code, there will be far less to change and it will take less time overall than trying to wing it off the bat.
Slashdot Mirror
The problem's quite common, having been a TA for a few lower level university programming classes, and graded the things. I think it comes down to force of habit. Although we're told a million times to code on paper first, and on a machine later, hardly anyone does, because an editor is as good a tool as any to layout structure and flow of control through function definitions and user defined types. The habit backfires when it comes to using paper. The way I'd recommend to tackle such exam questions, is to start off with a bunch of scratch paper and draw the bigger picture. Then refine bits and pieces, filling in functions, formalizing parameters, and so on. Finally bring it all together. Then when you write the code, you're working off a solid draft. I realize that this is time consuming and seems contrary to the time restricted nature of exams, but it's likely that once you do put down the code, there will be far less to change and it will take less time overall than trying to wing it off the bat.