Saturday, June 03, 2006

Reading Code

Most computer science departments are paranoid about copying code. The problem is that it's so easy to do it. There's now any number of ways to copy code from email to IM to ftp. There is some software to check for some kinds of cheating, but not everyone is aware of it.

It's a shame that about this paranoia because people really need to learn to read other people's code besides their own. In an English class, where a teacher would read each and every person's essay, as there is no automated way around this, catching cheating is straightforward enough. Too bad you can't convince computer science deparments to think like this, to keep the number of students down so that every person's code could be read.

Although reading code is not a new idea--some computer science teachers have been advocating this idea for a long time, there is a problem. English classes have the benefit of good writing being available and studied for a long time. In addition, critiquing writing has also been around for a long time. Those who teach writing know what to do because they were trained this way.

For a computer science department to talk about code would mean that those teaching it would need some idea of what good or bad code looks like, and that's tough. Without having a communal history of what makes good and bad code, a person is likely to criticize code that is fine, in some context, and to not know about newer idioms in writing code that may be in somewhat common use among the "best practictioners" in the field.

The solution is to start creating public repositories of code with annotations by many readers, something akin to ancient Hebrew texts that are commented on by a variety of Talmudic scholars. I'm surprised this hasn't happened yet. The quality of code should vary from very good to simply awful.

The benefit would be to make programmers more aware of aesthetics of coding.

Admittedly, there's more to coding than simple aesthetics. That's a topic I'd like to explore at some other blog entry, in particular, how testing can make you a better coder.

No comments: