Previous Page
Next Page

Chapter 1. Best Practices

We do not all have to write like Faulkner, or program
like Dijkstra. I will gladly tell people what my
programming style is, and I will even tell them where I
think their own style is unclear or makes me jump
through mental hoops.
But I do this as a fellow programmer, not as the Perl
god ... stylistic limits should be self-imposed, or at most
policed by consensus among your buddies.
Larry Wall
Natural Language Principles in Perl

Code matters. Analysis, design, decomposition, algorithms, data structures, and control flow mean nothing until they are made real, given form and power in the statements of some programming language. It is code that allows abstractions and ideas to control the physical world, that enables mathematical procedures to govern real-world processes, that converts data into information and information into knowledge.

Code matters. So the way in which you code matters too. Every programmer has a unique approach to writing software; a unique coding style. Programmers' styles are based on their earliest experiences in programmingthe linguistic idiosyncrasies of their first languages, the way in which code was presented in their initial textbooks, and the stylistic prejudices of their early instructors. That style will develop and change as the programmer's experience and skills increase. Indeed, most programmers' style is really just a collection of coding habits that have evolved in response to the opportunities and pressures they have experienced throughout their careers.

Just as in natural evolution, those opportunities and pressures may lead to a coding style that is fit, strong, and well-adapted to the programmer's needs. Or it may lead to a coding style that is nasty, brutish, and underthought. But what it most often leads to is something even worse: Intuitive Programmer Syndrome.

Many programmers code by instinct. They aren't conscious of the hundreds of choices they make every time they code: how they format their source, the names they use for variables, the kinds of loops they use (while vs for vs map), whether to put that extra semicolon at the end of the block, whether to grep with a regex or a block, where and when to put comments, whether to use an object-oriented or procedural approach, how to explain their programs in their documentation, whether to return undef or throw an exception on failure, how to decompose the different components of a system into subroutines, how to bundle those subroutines into modules, how to interact with the program's user.

Developers are usually focused entirely on the problems they're solving, the solutions they're creating, and the algorithms they're implementing. So when it comes to choosing a variable name, they use the first one that comes to mind[*]; when it comes to using a loop they use the one they always use[]; and when it comes to that trailing semicolon, well, sometimes they do and sometimes they don't. Just as the spirit moves them.

[*] Often whatever is short, vaguely relevant, and easy to spell: $value, @data, $next, %tmp, $obj, $key, @nums, %opt, $arg, $foo, $in, %to, $fh, $x, $y, @q, and so on.

[] The three-part C-style for loop: "It's so flexible! What more do you need?"

In The Importance of Being Earnest, Oscar Wilde captures the nature of the Intuitive Programmer perfectly:

Lady Bracknell:

Good afternoon, dear Algernon, I hope you are behaving very well.

Mr Moncreif:

I'm feeling very well, Aunt Augusta.

Lady Bracknell:

That isn't the same thing at all.
In fact in my experience the two things rarely go together.

And so it is with many programmers. They write their code in the way that seems natural, that happens intuitively, and that feels good.

Unfortunately, if you're earnest about your profession, comfort isn't enough. "Behaving very well" may seem stuffy and conventional and uncreative and completely at odds with the whole outlaw hacker ethos, but it has one important advantage: it works. Good social manners help societies run smoothly; good programming manners help programsand programming teamsdo the same.

Rules, conventions, standards, and practices help programmers communicate and coordinate with one another. They provide a uniform and predictable framework for thinking about problems, and a common language for expressing solutions. This is especially critical in Perl, where the language itself is deliberately designed to offer many ways to accomplish the same task, and consequently supports many incompatible dialects in which to express any solution.

The goal of this book is to help you to develop a conscious programming style: to train yourselfand your teamto do things consistently in a way you've decided is correct, rather than in whatever way feels good at the time. Or, if you prefer your metaphors more Eastern than Edwardian: to help you move beyond the illusion of the sensual programming life, and become stylistically enlightened.

    Previous Page
    Next Page