I was talking to Gavin Estey on iChat about the problems inherent in interviewing a new programmer. The cost of screwing up can be enormous. How do you find out whether the candidate is for real? How do you do it quickly?

Well, those are sticky questions, and there’s a discussion of Perl certification and standards coming up once I’ve marshalled my thoughts properly.

Anyway, Gavin showed me one of the quiz questions they used in his organization:

What’s wrong with the following code?

open FILE, "<$filename";
print FILE '$parameter1, ';
print FILE '$parameter2, ';
print FILE '$parameter3\n';
close FILE;

Here’s my thoughts, in the order I came up with them:

1. Where’s the or die "Can't open $filename: $!" at the end of the first line?
2. Globally scoped filenames are bad, m’kay? That first line would be better written as: open my $fh, '<', $filename or die "Can't open $filename for reading: $!"
3. Why so many print statements? And what kind of variable names are those? Replace $parameter1, $parameter2, $parameter3 with a parameter array. Then those print statements could become { print join(', ', @parameter), "\n" }, which is a little ugly, so extract the hack into a helper function, let’s call it sprint_list.

So, the code becomes

sub sprint_list { join ', ', @_ }

open my $fh, '<', $filename or die "Couldn't open $filename for reading: $!";
print $fh sprint_list(@parameter), "\n";
close $fh;

Given time I’d do something about sprint_list so I could just do println_list $fh, @parameter, but this is, after all, only an interview quiz I’m doing for fun.

Now, these are all matters of style, rather than syntax. The thing I completely missed when I first looked at the code was a simple matter of syntax that would have leapt out at me if I’d actually tried to run the code. The deliberate mistake in the above code stems from the use of single quotes instead of double quotes. Of course, the rewritten code fixes that bug almost incidentally — Gav actually had to point it out to me.

Which set me thinking. I contend (and I would do wouldn’t I?) that the kind of mind that looks at that code sample from the point of view of good style and tries to fix that is more useful as a programmer than the one that looks at the code and sees the typos. It’s a little like the difference between a proofreader who reads a manuscript looking for literals, and the far more useful editor who reads the manuscript gives feedback which improves its readability.

This comes back to the point that (I think) Larry Wall has made regarding programming languages: The reason for writing any program in a high level language is to communicate the original programmer’s intent to other programmers. If they were purely for telling the computer what to do we might as well be programming in assembly language. Given this, the programmer’s job becomes the same as that of the writer—to communicate effectively with other human beings. And we do that through good style, not through good spelling.

Of course, at some point we’re going to have to make sure that all the is are dotted and the ts are crossed in our program, but that’s why we have the ‘-w’ switch, test suites and all the other paraphenalia.

I have the feeling I shall be returning to this area soon.