Wednesday, July 31, 2013

Trick Questions Are A Bad Idea

Thanks to a post by Mark Guzdial I found What Makes Code Hard to Understand? This was a report of a study looking into what makes cade hard to understand even for professionals. I ran though one or two of the exercises and found that I came up with more wrong answers than I’d like to admit. (Actually any at all is more than I ‘d really like to admit.) I am tempted to just write this off as they examples being in Python which is a programming language I know almost nothing about. In reality I should know better than to make some of the assumptions I did make. In real life you wouldn’t want professionals to write code like most of these examples. A good code review (do people still do code reviews?) should correct most of them. On the other hand these are the sorts of “puzzles” that teachers like to include on tests and quizzes. I started to wonder if this wasn’t actually a problem that we have ignored.

There is a tendency to write test/quiz code that is less than completely clear. The theory is that this requires students to read the code closely and understand all the little details (things like side effects) of the code to properly answer the questions we ask. This is just one way that we use bad code with students though. A lot of times we do things to force a focus on specific features and functions of code. One of my forever students complained that the code in the AP CS exam has loaded with examples of how not to write code. And I could not disagree.

The problem that concerns me is that by using bad code (by various definitions of bad code) we expose students to more bad examples than good examples. We as teachers can say “don’t write code like this because we’re just using it to test you” but we know that “do as I say not as I do” is generally bad technique for anything. A student who spends time figuring out “trick code” is likely to start thinking that this is the way to write code. Oh they may even know that the code is hard to read, hard to understand and even risky for production code. At the same time they may see this as being an example of showing how smart they are – they can understand this tricky stuff. If so bad habits can easily be developed.

I’m going to do my best to write easy to understand and easy to read code even for tests and quizzes this year. I think I need to set a good example as much as possible.

No comments: