Learning from Bad Code

I’ve written before about Linux Format’s habit of sharing badly written Perl code. I thought things were improving, but in the new edition (November 2012, issue 163) they’re back to their old tricks.

This time it’s a tutorial called “Starfield: Learn new languages”. In this tutorial Mike Saunders writes similar starfield simulation code in C, Python and Perl. Mike’s loyalties are made perfectly clear when these three sections are entitled “Low Level”, “High Level” and “Unusual Level” respectively, so I wasn’t expecting much. But here’s what I got.

Let’s be clear here. This code works exactly as Mike intended it to. But if you’re writing sample code for other people to learn from, I think you should be setting the bar a little higher than “works for me”. I think you should should be aiming to show people good quality code that can be easily mainitained. And this code falls well short of that aim.

Let’s look at some of the problems in more detail:

  • No use strict or use warnings. Let’s be generous and assume the editor removed them to save space.
  • Undeclared variables. Of course. if the code contained use strict then the variables would all have had to be declared. Not declaring them means that we’re using package variables rather than lexical variables. In code this simple it doesn’t make a difference. But it’s a bad habit to get into.
  • Indirect object notation. When creating the Curses object the tutorial uses the syntax $screen = new Curses. Again, not a problem in this program, but a really bad habit to be encouraging. In the article’s defence, the documentation for the Curses module only includes this flawed syntax.
  • Split data structures. The author of the article says “instead of having an array of stars containing coordinates and speeds for each one (i.e. an array of arrays), to make things simpler we’ve just set up three arrays.” I read this to mean “I’ve never been able to work out how to make arrays of arrays work in Perl so I’ve taken the easy way out.” This is, of course, a terrible idea. Linked data items should be stored in the same data structure.
  • C-style for loops. The mark of a C programmer who never really got to grips with Perl. The C-style for loop is rarely used in Perl code. The foreach loop almost always leads to more readable code.
  • Magic numbers. The size of the screen and the maximum speed of the stars appear as numbers in the code. Even if you’re not a Perl programmer, surely you would know that it’s good practice to move those into variables or constants.

With all that in mind, here’s my version of the program.

What do you think? Is it more readable? Easier to maintain? Are there any problems or improvements that I’ve missed?

Google Currents

Google Currents is an application for viewing content on Android and iOS devices. It reformats content (based on web feeds) to look like a magazine. It looks great on my HTC One X and I’m expecting it to look even better on my Nexus 7 when it arrives.

It’s possible to subscribe to web feeds using it, but for some reason content looks better if the web site owner goes through a simple process to publish the content. This is literally a three minute job which you do from the Google Currents Producer web page. I’ve done that for both this site and the Perl News web site. I can’t seem to find any way to share the address of this content, but if you open the Currents app on your tablet or phone and search for “Perl Hacks” and “Perl News” you should be able to find them.

Currently I’m using all the default formatting options, but I suspect I’ll be drawn into tweaking things soon.

If you published Perl-related content on the web (or, indeed, any other kind of content) then it might well be worth your while taking the three minutes it takes to publish your content for Google Current.

More Modern Perl in Linux Format

Yesterday’s post bought my subscription copy of Linux Format issue 153. This issue contains the second article in my short series about Modern Perl. In this article we take the simple DBIx::Class application that we wrote last time and put a web front end on it using Dancer.

Over the next few days I’ll be writing the third (and final) article in the series. This will involve adding more features to the web app.

If the series is successful (and please let LXF know if you liked it) then perhaps I’ll be asked back to write more next year.

LXF 153 should be appearing in all good newsagents next week.

Doomed Domains

Summer is YAPC time. And YAPC means getting inspired on Perl-related projects. And that, obviously, means buying domain names for those projects. And that, inevitably, leads to lots of email from domain registries at about this time of year which roughly translate to “are you ever going to do anything useful with that domain you bought a couple of years ago, or should you just face facts and let it go?”

This year’s batch brings memories of projects from the last three years.

In Copenhagen in 2008 I gave a talk called Proud to Use Perl. To back it up I started a blog where I planned to share things that made me proud to use Perl. It didn’t last long. Even when I brought a team to help me, no-one had the time and nothing has been written there for two years. An advocacy site like that does more harm than good unless it it kept updated. So unless someone wants to take over the site (and keep it up to date) I’m going to let the domain lapse.

Lisbon in 2009 seemed to be largely about getting the Perl marketing project up and running. It was the scene of the famous Perl Marketing BOF. One of the ideas that came out of it was that Perl needed better web sites. I registered perlfive.com and perlfive.org in order to… well… I’m not really sure what they were for. Currently they both just redirect to perl.org. Do you have a better use for them?

And then last year in Pisa we had Perl Vogue. I was learning by that point and only registered the domain for a year. I’d really love for the Perl Vogue idea to really take off, but I’m not going to be the one to do it. If you want to try, then let me know.

Most of these domains expire some time in July. If you have ideas of what we can do with them then please get in touch. But, be aware that any suggestions that start “couldn’t you just…” are likely to be ignored. I’m looking for suggestions that start “I’d like too…”.

An Open Letter to Linux Format

Back in September 2010 I wrote a piece criticising the way that Perl had been described in a recent issue of Linux Format. In a response to my article, the editor wrote:

And, believe it or not, I do care about Perl. I met Paul Fenwick a few months ago, and he agreed to write a Perl tutorial series for us – I hope you agree with my choice!

So when I saw that a new series of Perl tutorials was starting in the “Coding Academy” supplement of the new issue (#149, June 2011) I was looking forward to reading a useful introduction to the language written by Paul Fenwick.

Unfortunately, I was disappointed. The tutorial was written by Marco Fioretti and, to be honest, it really wasn’t very good. It failed on three fronts.

  • The English wasn’t very good
  • The explanations of Perl were, in places, rather out of date or just plain wrong
  • The sample Perl code included some rather outdated practices

Let’s look at those three areas in more detail.

English Language

Obviously, English isn’t Marco’s first language. And his English is far better than my Italian. But I’d like to think that if I was writing for an Italian magazine, then the editors would tidy up my writing so that I didn’t make myself look too foolish. It appears to me that the Linux Format editors did nothing to correct Marco’s English. Here are a few examples of infelicities that slipped through.

“Before looking at the code, however, let me explain which data it uses…”
“Perl arrays and hashes are much more flexible than it shows in these pages…”
“The complete code of the procedures is in the DVD”

Of course, there’s nothing terrible there. We know what Marco meant. But the magazine would have looked a lot more professional if the editors had taken the time to edit this article.

Misunderstanding Perl

Marco’s knowledge of Perl seems a little mixed up or out of date in places. For example, he says:

You call a subroutine by adding a & to its name and passing parameters

It’s been several versions of Perl since the & has been required on a call to a subroutine. You won’t see it in any modern Perl code. It just makes the code look unnecessarily messy. Later on in the article, Marco says:

Perl does have while, if, for and unless, but it lacks a C-like switch operator for multiple, mutually exclusive choices.

The Switch module was added to Perl in version 5.8.0 (in July 2002). A much improved version called given/when was introduced in version 5.10.0 (in December 2007). Anyone who thinks that Perl doesn’t have a switch statement simply hasn’t been keeping up.

Outdated Perl

The Perl idioms that Marco uses are often somewhat outdated. In particular he uses the two-argument version of open instead of the safer three-argument version. He also uses global filehandles instead of lexical ones.

Marco also has a rather distinctive style for his Perl code, much of which runs counter to the advice in the perlstyle manual page or the Perl Best Practices book. In particular, his use of capital letters for variable and subroutine names will look very strange to someone used to reading Perl code formatted in a more traditional manner.

All in all, I think that Marco’s style does nothing to counter the reputation that Perl has for encouraging unreadable code and that with a little thought the same program could have been written in a far more readable manner.

Marco’s attitude to keeping up to date with Perl is nicely demonstrated by the books he recommends. “Programming Perl” and “The Perl Cookbook” were last updated in 2000 and 19982003. He would have been far better off recommending “Learning Perl” (which does keep up to date – the fifth edition was in 2008 and the sixth is currently in progress) or Modern Perl.

It’s a shame that the promised series of articles by Paul Fenwick hasn’t materialised. But it’s even more of a shame that Linux Format has fallen back to using articles written by someone who is not interested in keeping up to date with modern Perl. In light of this disappointment, I’d like to make the following offer to Linux Format.

If you want someone to write an article about Perl (whether that’s a one-off article about a particular topic or a series of tutorials), if you get in touch with me then I will find the best person to write that article for you. I may even do it myself if I have the time and the knowledge. Further to that, I am more than happy to proof-read and edit any Perl articles that you have currently in the pipeline.

I don’t believe that the Perl community in the UK is particularly difficult to track down. but if I’m wrong then I’m quite prepared to the the conduit that people to use to contact the community.

[I’ve found the sample program from the tutorial on the CD and have put it online.]