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.
Here's the short version:
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:
- What if I don't have code ...have too much code, or don't understand an error message?
- How should I name my question?.
- Can I get help without posting a question?
- Preview, preview, PREVIEW!
Now, if you're wondering "Where to ask?" the answer is here.
BUT please come back soon, and read the rest of this.
Here's more extensive advice:
First and foremost, think through your question.
- Can you explain it clearly to yourself?
- Can you explain it to others?
- What example data would help them understand the issue?
- What's not happening that you think should happen, or happening that you think should not (or don't understand)?
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).
Show us that you've made an effort.
- Show your code (at least the problematic snippet)
- Explain in detail what you get (include sample output, error messages and warnings, for example).
- Tell us how your output means your script isn't working.
If you do, it's likely someone will provide pointers in the right direction.
Now you're getting close to a good question.
Code, no code and errors
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.
Select an informative title.
"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.
OK, but can I get help without posting a question?
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.
But I never asked that question before!
No, but surely you don't think you're the first to come to the mountaintop seeking that wisdom, do you?
But I'm new at this; I don't know what search terms to use!
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.
And a few added points:
- Log in before you post unless you want it to be anonymous (and remember that that anonymonk can't update a node nor get notifications of replies).
- Don't ever wipe the original content of any node you've written, even if you've solved your problem; you're clarifying your issue; or you realize you just made a "D'oh!" Mark the changed/new content with the word "Update." Don't delete! Doing so is likely to make replies you've received unintelligble to future readers. Use <strike> ... </strike> if you must.
- Be patient. And don't tout your node in the CB.
- Don't post real email addresses, usernames, or passwords
- Own up to homework. (We may help with homework when you show some effort, but you're not learning anything and we're not helping if we do it for you.)
- Understand that the Monastery is NOT a code-machine. Don't ask for a handrolled script to suit your needs. That costs $$$$.
- RTFM -- the various FAQs, guidance and tutorials on our standards, as well as those on Perl.
But all I wanted to know is "where to post my question?"
Wow! How can I thank you enough?
Adhere to these suggestions... and pass them on to others.
For Further Reading
For a much more comprehensive treatment of the subject, check out Getting Answers by Mike Ash.
But please keep in mind -- that site is not related to PerlMonks, and is not a resource for people seeking Perl help (nor any other kind of help, for that matter).
Back to PerlMonks FAQ