Friday, September 23, 2016

When But It Works Isn’t Enough

I saw this image on Twitter recently. It was captioned:

"Spaces or tabs?"
"Semicolons."

Semi

It’s all perfectly legal C or C++ code. And a decent compiler will handle it just fine. But oh is it ripe for bad things to happen. Of course this is just a humorous example. No one would ever do it. Right?

On the other hand I have seen some code that was pretty hard to read. Students need to learn the value of programs that people can read as well as the computer. Somethings that get in the way of people understanding code can lead to things the computer gets wrong as well. At best they make it hard to update, modify, enhance, or fix programs. A working program that is unreadable by people is not as useful as one that people can read.

Another  of the things I see regularly is student code that compiles and executes and gives the correct answers but is horribly inefficient. Or it takes advantage (often unintentionally) of side effects that are not always going to be consistent, for example across different libraries. Or they just plain do things the hard way.

I’ve been working with my students on loops and if statements. We created a program that works just fine for small samples but it doesn’t scale easily. By adding arrays we can make it much more scalable but we haven’t introduced arrays yet.  When we do they’ll see better, easier ways to do man things. This particular program will seem obvious to almost every student. Not all optimizations are as obvious though. This is something we have to teach.

Beginners are often ready to settle for “it works. it gives the right answer. What more does it need?” Eventually many of them will get to a point where performance is an issue. Or maintainability will be an issue. Sure many will never get there but increasingly I think we do students a disservice if we are willing to accept work that is not as good as it could/should be for the level of knowledge.

No comments: