Woxidu

I am anal about readable code. I think about it a lot. How code is spaced, how different variables and functions are named, how the abstraction I’m using is reflected in the way the code actually appears. These are all very important to me.

Most people who know me also know that I am a believer that Perl is a great language for writing supremely unreadable code. It always sort of seemed like the use of confusing syntax was the accepted “best practice” form of doing anything in the language. It’s now clear to me that perl was designed to promote confusion as the norm, and to offer readability as an afterthought.

Consider the following from a tutorial on building a foreach loop in perl:

The foreach loop is a control structure that’s tailor made to process Perl lists and hashes. Just like the for loop, foreach steps through each element of an array using an iterator. Rather than using a scaler as that iterator (like the for loop), foreach uses the array itself.

        @myNames = ('Larry', 'Curly', 'Moe');
        foreach (@myNames) {
            print $_;
        }

Only after clicking through to page two do we find something a bit more sane:

In the previous example, you’ll notice we used $_ to print each element of the list.

        @myNames = ('Larry', 'Curly', 'Moe');
        foreach (@myNames) {
            print $_;
        }

Using this default implied scalar ($_) makes for shorter code and less typing, but isn’t always the best solution. If you’re aiming for highly readable code, or if your foreach loop contains a lot of complexity, you might be better off assigning a scalar as your iterator.

        @myNames = ('Larry', 'Curly', 'Moe');
        foreach $name (@myNames) {
            print $name;
        }

I think this sentiment underscores my problem with perl nicely. Perl is a language to use if you like taking shortcuts and being tricky. Why else would the $_ approach be explained first? Think of the countless people who will read no farther than the first page and then charge ahead with their projects.

Even on principle, I think $_ is a bad idea. Who writes code for themselves and names a variable $_? What does that mean? How does its name or characteristics help me understand its purpose? How am I supposed to use it? How is its abstraction obvious?

Jumping back, the larger issue here is one of verbosity. How circumlocutory do I need to be to get my point across? Consider the Objective-C foreach which looks like this:

    for (NSString* name in myNames)
    {
        NSLog(@"%@\n", name);
    }

Note how I have to specify not only a name for my thing but also a type. While these can be a hinderance to the amount of time it takes for me to write code and will result in “more typing,” it completely expresses the point of what it’s supposed to do. There’s much less doubt that I’ll open up the code 7 months down the road and have no idea what $_ was supposed to mean.

</RANT>