This document tries to help you get help. These are not "rules for the sake of rules" but, rather, guidelines to help you help us to help you.
If you want to get good answers: Paste actual code that reproduces the problem between <code> and </code> tags . State exactly what the problem is. Be precise about the correct behavior / desired output. Additional background about what you are trying to do and what you have tried also helps. For example:
Now, if you're wondering "Where to ask?" the answer is here.
BUT please come back soon, and read the rest of this.
First and foremost, think through your question.
Write it down -- preferably in your editor on your machine.
Look away for a moment; perhaps mull the question over some more.
Edit for clarity and precision (leet-speek iz rong on both cnts!). Spelling and grammar count (but we try hard to understand if English is not your native tongue).
Repeat as necessary. It's often said and often true that explaining a problem to a rubber ducky or to a teddy bear will show you a solution.
Show us that you've made an effort.
If you do, it's likely someone will provide pointers in the right direction.
But before you post it, take another step. Include (inside <code>...</code> or <c>...</c> tags) a minimal script that reproduces your problem and sample data (input). Of course, if your problem is that you can't get the script to compile, despite your best efforts -- perhaps because the error message doesn't make sense to you -- go ahead and post the section where strict tells you that you have an error (and, of course, the error message, verbatim) It is ok to ask for help if you can't figure out why something won't compile. But let that be your question and save the "my script won't do X" question for later."
Use strict and warnings. Failure to use strict and warnings is a red flag; it tells us you didn't use the available tools ("aka, make an effort").
On the other hand, using these pragmas may show you how to solve your problem before you post. For example, they'll catch variables where you make a typo between assignment and use. Failure to use them is like ice-climbing without a safety line.
Again, use code tags without fail or the Monks' outrage may lead them to conclude, prayerfully, of course, that you need penance. In fact, failure to use at least minimal markup will almost certainly persuade some of the Reverend Brothers and Sisters to point you to the sackcloth and ashes in the third sub-dungeon. ( See Markup in the Monastery for quick reference or Perl Monks Approved HTML tags for an exhaustive list of what's allowed.) And be sure to close your tags; the special dialect of html used here is unforgiving about failure to close some tags.
See if what the preview screen shows looks like what you intended. And if it doesn't, fix your markup, and preview again. ONLY when your note "looks right" should the "Create" button tempt you.
"Need help ASAP" doesn't cut it. Neither does the name of any Perl function.
For example, if you're having problems dereferencing an array in a hash, SOPW ("Seekers of Perl Wisdom") won't accept a one word title like "%hashref"; %hashref problems" isn't fully descriptive; but "Why doesn't this deref the @arrays in my %hasref?" is probably OK.
Ah, I'm glad you asked.
Laziness is one of the virtues admired by Perl programmers -- in themselves or when demonstrated with competence and verve! It is not admired when demonstrated by a Seeker of Perl Wisdom who is too lazy to adhere to the hints above; who posts ambiguous questions; who fails to read the docs (see perldoc perldoc for an overview of the knowledge that's at your fingertips; or who inconveniences thousands of electrons to ask redundant questions.
No, but surely you don't think you're the first to come to the mountaintop seeking that wisdom, do you?
Super_Search is your friend. Use it! Or Google's advanced search against PerlMonks. Big G is quite good at finding nodes here that will help you, if you ask with reasonable search terms.
Ah, that plaint is sometimes justified, but have you read the manual How to RTFM? Did you look at the plethora of information available via perldoc or at perldoc.perl.org? The Tutorials may also speed your search for enlightenment.
There's a form at the bottom of the Seekers of Perl Wisdom page (but first, please go back to the top and actually read the suggestions).
Adhere to these suggestions... and pass them on to others.
For a much more comprehensive treatment of the subject, check out Getting Answers by Mike Ash.
This node is based heavily on — in fact it was originally a copy of — jeffa's excellent How (Not) To Ask A Question. The copy was made only so that SiteDocClan would have a version they could update as necessary. No plagiarism is intended.