|P is for Practical|
Common Beginner Mistakesby chromatic (Archbishop)
|on Dec 15, 2000 at 04:40 UTC||Need Help??|
Beginning programmers face a great learning curve. Beyond the syntax of their starting language, they must master the concepts of algorithms, data structures, and the idioms used to accomplish common tasks. Most of the books in my library concentrate on grammar, syntax, and standard libraries, while glossing over good practices and common mistakes.
Perl has its own unique set of gotchas and strengths. Some make it easy for beginners to hang themselves, and others could reduce the amount of code and heartache needed. (Perl is fairly unique among languages in that it often lets beginners and dabblers succeed despite their lack of formal training.)
Without further ado, here are Common Mistakes of Beginning Programmers (part one).
Variable Variable Names
The mistake:Beginners will often do something like this:
Why it's a mistake:Symbolic references are a well documented pitfall. Besides that, Perl has built-in and easy-to-use aggregate data types. That means that it makes a distinction between a thing and a pile of things. In addition, you will need to keep track of the index variable $i to know how many records you have.
Why they do it:Beginning programs are often unaware of genericity and aggregation. They like naming variables, and don't realize yet that you don't have to name everything that's ever created.
The solution:Use an array or hash (the aggregate data type) to hold the records. Not only will Perl keep track of the number of records, it's easier to do common operations on them.
Repetition without Abstraction
Yikes. At least he used CGI.pm, anyway. Here's another example:
Why it's a mistake:Computers are supposed to make our lives easier. Anonymous data structures, objects, loops, modules, macros, and templates are supposed to save effort. Why do people not get beyond cutting and pasting?
Problems arise, as they always do, when a throwaway program becomes important enough to keep around. Those programs have a way of attracting deadlines -- you'll have to add something, but you won't have time to do it right. Repeat that another way. There's no better time to do a program right than before anyone's depending on it.
Why they do it:Designing things that have to work just once is easy. Designing things that have to work a few different ways is difficult. Designing things that are flexible, powerful, and easily understood is even worse. A few extra minutes of typing seems like a small price to pay for not having to think too hard under a time crunch.
The solution:If you find yourself duplicating functionality in different places, stop. Factor out the common elements and turn the variables into variables. Sometimes this means you've been trying the wrong approach. Other times, you're not approaching the problem the right way.
A literal translation of the first, somewhat better:
A whole lot better:
The second is lots nicer:
Some items lend themselves to functions more than others. As you practice, you will improve at figuring out which things are important and which are variable.
Fear of Documentation
The mistake:Not typing 'perldoc perltoc'.
Why it's a mistake:The Camel has a list price of US $49.95. Getting answers from comp.lang.perl.misc, PerlMonks, and #Perl cost time and sometimes dignity. If you have access to a computer with Perl on it, you have access to the documentation -- the source material from which much of the Camel springs. (If you don't have the documentation, you have a more serious problem called "BoFH infestation". You'll have to fumigate.)
Why they do it:Some people don't know the documentation is there. A careful nudge "Hey, it's under the ActiveState program group or available by typing perldoc perltoc and browsing for a while" is all that's needed. Others don't have the confidence in their own abilities or the laziness necessary to motivate themselves into being able to answer their own questions.
The solution:Read the FAQ (perldoc perlfaq). Read perldoc perldoc. Learn how to search for builtin function docs (perldoc -f function). Learn how to search the FAQ by keyword (perldoc -q keyword). If you come across a word you don't know, see perldoc perltoc. Yes, it takes a while. So does learning to be a basketball player, a Bolivian cat herder, or an astroman. But the documentation is always there, even when we're not. When you don't have time to wait for a response from Usenet or the web, and when you're not in the mood to placate the IRC Ops, you'll be glad you know how to search your own hard drive for the answers.
Update: Fixed an unintentional typo in the first beginner code, thanks to turnstep. chipmunk is right... I'm open to writing a second-parter, so send me your suggestions. Fixed a second unintentional typo in the second example, thanks to erix.