Many times (generally inexperenced) SoPW posters take a few itterations before they get to a point where their question can be answered. There are a few basic reasons for this:
- data is not as you think and is not supplied with the write-up,
- output is not what you expect, but is not shown in the write-up,
- the problem is so poorly described that no one understands it,
- the problem assumes some local context that can't be reproduced or infered,
- warnings or errors have been ignored - possibly by not using strictures,
- too little code is provided to show the problem,
- so much code is provided that the problem is obscured.
Many of these problems can be avoided or resolved by reducing the problem to a small self-contained example that shows the issue and otherwise runs clean (no extraneous warnings or errors). A number of techniques can be used to achieve this: focus, accuracy, embeding and succinctness are the keys to good SoPW nodes.
How do you go about all that? Ensure you describe the problem and avoid extraneous cruft. Focus the code on the issue, not the context. Reduce the code to the smallest amount you can and still show the issue. (You may fix the problem yourself this way, but don't consider that a failure - even if you don't get any XP :-).) If you need data, embed it or generate it. Avoid all modules not directly related to the problem. Avoid IO that is not directly related to the problem. Avoid everything not related to the problem.
Start with the code that shows the problem and consider the minimum input and output requirements to demonstrate the problem. Then reduce the code and data as much as possible while still showing the problem.
How do you know when you have too little code? If the code won't run as is you don't have enough code. If use strict results in errors you have too little code (unless that is the issue).
How do you know when you have too much code? If there is a line, or even a character that you can remove and still show the problem you have too much code.
If the problem is not an IO problem, embed any required data in the code. One way to do this is to use a __DATA__ section to provide input data:
while (<DATA>) { print $_; } __DATA__ Hello world
If you need some start state, ensure that you create it.
my @emoticons = (':P', '*tongue*');
If you really need an input file to show the problem, create one:
open outFile, ">", "test.txt"; print outFile <<END; This is test data for reading by the example code. END close outFile;
If you need a 1G data base to show the issue, that's a problem. But chances are you can reproduce the problem with two modest size records, and supply them by creating a CSV file as shown above.
If you need to access a web page to reproduce the problem, use something that is likely to stay around for the life time of your node. The PM node itself is often a good choice!
When you post remember to use code tags and readmore tags. They won't affect your code, but may well affect the answers you get.
Remember to describe the output you expect to see. Best is to give a sample of what you get and a sample of what you want. Remember to actually run the code you are about to post to check it hasn't suffered bit rot since last you tried it. Copy & paste is your friend. Avoid retyping stuff you can just copy & paste, it's probably faster and certinally less likely to introduce typos.
Oh, and it seldom helps to describe your understanding of the nature of the problem - which sounds rather silly, but if you understood that, you wouldn't need our help would you? Concentrate instead on as suscinct a description of the symptoms of the problem as you can manage.
Oh, and remember to read Writeup Formatting Tips and What shortcuts can I use for linking to other information?. Remember also that if your indentation is crap people will give up on it - sometimes you just have to go with the flow (PerlTidy is your friend).
DWIM is Perl's answer to Gödel