While the information in the above article is useful, it comes off as a
lecture. In general people don't react well to "shoulds". In particular
people who
should be doing specific things are likely to being
told that outright. Therefore I recommend a somewhat different tone.
For an example of how to do that, here is a rewrite that shows what I
mean. While I am making the same points, in the same order,
I believe that this rewrite is more likely to inspire people to follow the good advice.
Here is a list of suggestions of how to improve your chances of success
when you ask a question. Some of these suggestions are likely to let
you answer your own problem. Others will help ensure a useful response.
- Use the -w flag.
As is pointed out in use warnings vs. perl -w, this turns on optional error
messages. This will often identify real problems much faster than
we can.
- Use strict
strict.pm turns on various useful restrictions. These are
admittedly a bit of a pain at first, but experience suggests that
it is well worth it for anything over about 20 lines or so. The
nicest thing that it does is catch many frustrating and confusing typos
in variable names.
- Use diagnostics
Many of the error messages that Perl gives can be confusing. What
diagnostics does is add explanations to the error messages. These
explanations are less confusing and often include an educated guess
at how to fix your problem. (This information is also available if
you type, "perldoc perldiag".)
- Explain "not working"
When something doesn't work there are generally many things that
could be wrong and we have no way to guess at the problem without
some information to narrow it down. So it is very good if you can
give us as much as you can to work with. Typically that includes
a description of what you were doing, any error messages, anything
you can find in a log file (for CGI scripts this is likely to be the
server log and its location depends on your webserver configuration),
and so on. Without this we can only guess.
- Say what you tried
This gives us context. Without it the best we can do is assume that
you tried nothing and start with the most basic and obvious stuff.
If you have tried it, you probably don't want to hear, "Is the server
plugged in? Is it turned on? Is Apache running? Can you ping the
machine?" But if you don't tell us that you can reach the machine
and Apache is running, it may be the best advice we can give. So
tell us that up front and you will save everyone some frustration.
(As a side benefit people generally prefer answering questions when
they have some evidence that the asker is giving it an honest
effort.)
- Describe your environment
Take a look at the output of "perl -v" for an example of what is
useful here. The more we know about your situation, the better the
chance that it will click with the right tidbit that we need to
give an answer. For instance the fact you are behind a firewall
makes a world of difference if you have trouble doing an ftp
download. Being on Windows makes a huge difference if your question
involves fork.
- Did you check CPAN?
CPAN is a vast collection of
modules and other code from Perl programmers around
the world. Very often you can find a solution to your
problem which has been tested and debugged there far
more easily than you could write it for yourself. Even
if you don't find something that does exactly what you
want right now, you often will find a solution for
another problem, you have or will have to solve. Plus
just studying the approaches and code of other people
is a great way to learn more about how to use Perl.
- Please use CGI
If you are writing CGI applications, you should be using CGI.pm. The
CGI protocol is deceptively simple. While it is easy to hand-roll
code that sort of works for a while, it is generally a very bad
idea to even try. See use CGI or die; for details.
- Show us the code
Everything you can do to reduce how much we need to guess will
improve our chances at providing a good answer.
- Show us sample data
Knowing what your code breaks on is really useful. If your download
breaks on a site, give us the URL. If your database loading routine
is failing, show us what it works on and what it fails on. Don't make
it excessive, but a small sample of what you are working with often
makes a world of difference in how helpful we can be.
- Write clearly
Please try to use proper grammar, punctuation, and spelling. When
you don't do that, the message that we get is that you don't care to
put any energy into communicating with us. If you don't think it
worth communicating with us, why should we communicate with you?
This isn't a test. After all many people here don't speak English as
a first language. We try to be forgiving. But if you can make a good
impression, try to.
- CGI is complex
CGI scripts have their own set of challenges and when they go wrong
do not provide as much (useful) feedback as you want. Most of
the time you can get more useful messages if you try to run it from
the command line. Likewise using CGI::Carp's
':fatalsToBrowser' you can get useful error messages out. And it is
a very good idea to run through the points in
The Idiot's
Guide To Solving CGI Problems. The tone is regrettable, but the
information is solid and will turn many problems into past headaches.
- Keep it appropriate
This site is fairly specifically for people who are trying to learn
more about Perl. We are not here to answer questions about other
languages, or for doing your homework. Moreover we are likely to get
annoyed if you ask us to do that.
UPDATE
Thanks to myocom for suggesting that I say CGI.pm at
one point rather than CGI. I also fixed the omission of
a blurb on CPAN.