|No such thing as a small change|
I know what I mean. Why don't you?by GrandFather (Cardinal)
|on Nov 22, 2005 at 10:42 UTC||Need Help??|
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:
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:
If you need some start state, ensure that you create it.
If you really need an input file to show the problem, create one:
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