In this second part of a three-part series on Perl programming, you'll learn how to structure your programs, and how to use statements. This article is excerpted from chapter one of the book Beginning Perl, Second Edition by James Lee (Apress; ISBN: 159059391X).
One of the things we want to develop throughout this book is a sense of good programming practice. Obviously this will not only benefit you while using Perl, but in almost every other programming language too. The most fundamental notion is how to structure and lay out the code in your source files. By keeping this tidy and easy to understand, you’ll make your own life as a programmer easier.
Documenting Your Programs
As we mentioned earlier, a line starting with a hash, or pound sign (#), is treated as a comment, and ignored. This allows you to provide comments about what your program is doing, something that will become extremely useful to you when working on long programs, or when someone else is looking over your code. For instance, you could make it quite clear what the preceding program was doing by saying something like this:
#!/usr/bin/perl -w
# print a short message print "Hello, world!\n";
A line may contain some Perl code, and be followed by a comment. This means that we can document our program “inline” like this:
#!/usr/bin/perl -w
print "Hello, world!\n"; # print a short message
When we come to write more advanced programs, we’ll take a look at some good and bad commenting practice.
Keywords
A keyword is a term in Perl that has a predefined meaning. One example would be the termuseas we saw in the statement
use warnings;
Other types of keywords include built-in functions such asprint()and control flow constructs such asifandwhile. We will talk about many built-in functions and control flow constructs in detail as we progress in our discussion of Perl.
It’s a good idea to respect keywords and not give anything else the same name as one. For example, a little later on we’ll learn that you can create and name a variable, and that calling your variable$printis perfectly allowable. The problem with this is that it leads to confusing and uninformative statements likeprint $print. It is always a good idea to give a variable a meaningful name, one that relates to its content in a logical manner. For example,$my_name,@telephone_numbers,%account_info, and so on, rather than$a,@b, and%c.