Brian's Guide to Perl (zz)

Document directory

• My debugging Philosophy

Title

Brian's Guide to Perl

Outline

Read this guide and stay informed

Describe my debugging Philosophy

I believe there are three things:

This is not a personal issue

Don't always think about your code. You may think you are an artist, but in fact, even experienced masters will write a lot of junk. Everyone's code is rubbish, and mine is yours. Learn to like it. When you encounter a problem, you should think: "Oh, there is something wrong with the junk code I wrote ." This means that you no longer blame Perl. It should not become a matter of personal nature.

Forget what you did before. If it is not your way of doing things, you will not read this. This is not a bad thing, but it is time to grow. We have all experienced.

Personal Responsibility

If your code has a problem, it's just your problem. You should do your best to solve it yourself. Remember, everyone has their own code, and everyone has their own problems. Do your own homework and do your best before you bother others. If you still cannot solve the problem after following this guide, you have tried your best and should look for someone else.

Change the way you do things

Do not make the same mistake after correction. It is very likely that the method you write code is wrong, rather than the code you write is wrong. Change the way you used to do things and make your life easier. Don't count on Perl to get used to you, because this is impossible. You need to get used to Perl. It is just a language, not a way of life.

My method:
Do you use strictures to compile code?

If you do not need strictures, open it. Perl experts are masters because they use strict mode, so that they have more time to solve other problems, learn new things, and upload modules to pour CPAN.

You can use strict pragma to open strictures in the code

use strict;

You can also enable the perl-M switch in the command line:

perl -Mstrict script.pl

You may be angry with it, but after using it for a few weeks, you will write better code and spend less time checking for low-level errors, and you may no longer need to read this guide.

What is warning?

Perl will warn you of problematic structures. Open warning and ask Perl to help you. You can enable the perl-w switch in the first line:

 

#!/usr/bin/perl -w

You can also open warning in the command line:

perl -w script.pl

You can also use Word warnings with many interesting features. For more information, see the help documentation of warnings.

use warnings;

If you do not understand the meaning of a warning, you can use the warning verbose mode, or use the pragma diagnosis in your code:

use diagnostics;

Solve the first problem first!

After you get a warning or error message from Perl, first solve the first problem and check whether Perl still reports other errors. Because subsequent errors are probably derived from the first error.

Check the code before the error message line number!

Perl reports an error only when the error has occurred, instead of before. Therefore, when Perl returns a row number, the error has already occurred, and the error is before this. Check whether there is a problem with the code and expression before the wrong line number.

Is that variable value what you think?

Don't guess! When using a value in an expression, check whether it is correct. Print is the best Debugger in the world.

print STDERR "The value is [$value]/n";

I enclose $ value in parentheses because I can see whether there are spaces or line breaks at the beginning and tail. If this value is not a scalar, I use Data: Dumper to print the Data structure.

require Data::Dumper;print STDERR "The hash is ", Data::Dumper::Dumper( %hash ), "/n";

If the printed result is not what you expected, move it to the previous sentence and try again! Find the correct position for this value. You can also use the perl-d switch to open the built-in Perl debugger. For more information, see perldebug.

perl -d script.pl

You can also use other debuggers or development environments to think about ptkdb (a Tk-based graphical debugger) or Komodo (ActiveStates Perl IDE Based on Mozilla)

Is the function you are using correct?

I have been writing perl programs for a short time, but I still need to check perlfunc almost every day. Sometimes I am so sleepy that I don't know why sprintf () is not printed on the screen.

You can use the perldoc command and Its-F switch to query a specific function.

perldoc -f function_name

If you are using a module, query its documentation to see if you are using it in the correct way. You can use perldoc to query its documents.

perldoc Module::Name

Are the special variables you use correct?

Similarly, I often query perlvar. However, when I find it easier for Perl to quickly refer to this book (The Perl Pocket Reference), I will rarely query perlvar.

Are you using the correct module version?

Some modules may change a lot during the upgrade. Do you know what version of the module you are using? You can use a line of perl statement to check your module version:

perl -MModule::Name -le 'print Module::Name->VERSION';

If the document you read is not a local document on your machine, but a document like a http://www.perldoc.com or a http://search.cpan.org, then you may encounter document version differences.

Have you tested it with a small script?

If you are trying new things or think a short piece of code is strange, you can write the shortest program to run this piece. This method excluded all other factors. If the test is normal, the problem may not be in this Code. If the test result is incorrect, you probably find your problem.

Have you checked the environment?

Some items depend on environment variables. Are you sure your environment variables are correct? When the program runs, is the environment variable you see now? Remember that some CGI programs or cron may use different environment variables than those in shell, especially on different machines.

Perl stores environment variables in % ENV. If you need an environment variable, even during testing, remember to provide a default value if it does not exist. If you have any questions, check your environment.

require Data::Dumper;print STDERR Data::Dumper::Dumper( /%ENV );

Have you tried Google?

Others may have encountered the same problems as you. Search by Google Groups (http://groups.google.com) to see if someone posted a similar post on comp. lang. perl. misc. Maybe someone else could find a solution. The difference between people who ask questions in newsgroups and those who answer questions is that they use Google Groups to have a high performance.

Have you tested the program performance?

If you want to know what causes your program to slow down, have you tried performance testing? Let Devel: SmallProf help you do this. It can calculate the number of times and time spent executing each line of code in perl, and then print a beautiful report.

Which test did not pass?

If you have a set of tests, which one fails? You can easily find the error, because each small test only executes a small piece of code.

If you don't have one, why not write one? If your code is short or short, or it is just a one-time program, I do not recommend that you write a set of tests. However, if this is not the case, it is helpful to write some test code. Test: Harness makes it so easy that you cannot find a reason not to do so. If you say you don't have time, you probably waste too much time debugging scripts because you don't need to test them.

Have you spoken to bear?

Speak out your question. Turn it into a language. For a few years I had a great pleasure working with a very good programmer who could solve almost any problem. When I get blocked, I always ask him to explain my problem to him. Almost every time it was like this: if I couldn't say the third sentence, I stopped and said, "Oh, I understand, no problem ." This is what he does every time.

You may need to do this too many times, so I recommend using a plush toy as your Perl clinical diagnostics so that you will not get angry with your colleagues. There is a bear next to my desk. I explain my problem to him every time. Every time I talk to myself, my girlfriend and Ben don't pay attention to it. She is used to it.

Does the problem look a little different on paper?

Because you always look at the computer screen, maybe a new media can let you look at this problem from a new perspective. Print the program on the paper.

Do you watch Jon Stewart?

To be honest. Maybe you don't like Jon Stewart very much. Take a break and stop for a while to relax your brain. When you come back, the problem may suddenly be easily solved.

Are you sure you want to check yourself?

If you have not solved the problem at this step, it may be a psychological problem. Maybe you have special feelings for a piece of code, so you don't want to get rid of it. Maybe you think that only you are right and everyone else is wrong. When you feel this way, consider the source of the problem-yourself. Do not be conceited and unwilling to recognize your mistakes.

 

Author

Brian d foy,

COPYRIGHT

Copyright 2002, Perl Documentation Project, All Rights Reserved