You ask a complex question that I frequently struggle with myself. Looking for an answer I stumbled onto your question, but I feel the answers so far don't really address what you asked. I will share my own thoughts, hoping to incite some more debate.
People post questions on SO for a number of reasons: homework, project due, learning but stumped, hobby projects, serious and deep issues, curiosity, ... And just as there are many types of questions, there are many possible answers. So the short answer to your question is
A longer answer: I use the following rules of thumb, based in part on my assessment of the OPs skills (a user whose question suggests inexperience may benefit from a more complete answer; a more advanced user may have overlooked something obvious and simply needs to be pointed in the right direction) and urgency (if you are drowning you are less interested in the correct technique for breast stroke, and more in a lifeline). But always, I hope to give the OP an answer that helps them, in their situation , and is possibly educational while I'm at it:
case 1 : no sense of urgency, trivial question
Usually asked by a Rep=1 person. I initially give a "hint" of an answer. Of the type Q: "Why does my program crash at the
scanf line?" - A: "Check the function prototype. Are you passing a valid pointer?" I will often post such answers as a comment rather than answer. I think in this case, being pointed in the right direction is often all that is needed, and the OP will remember better for having done some of the work. Someone else may come along and post essentially the same answer as an answer.
case 2 : urgent but trivial
If I get a sense of desperation from the way the question is asked, then, using the same example as above, I would rewrite the single line of code with a brief explanation. The emphasis is less on learning, and more on "get me out of this hole".
case 3 : badly phrased question with some non-working code samples.
I will usually start with some comments to get clarification; if that doesn't help I may write a short "I think you are trying to do this" sample, inviting comments to improve as needed. Usually the OP just doesn't understand how to ask a good question and needs some help phrasing it correctly. A recent example that I encountered is here
case 4: insanely complex question with essential code missing
Too much code posted, yet not enough to be able to reproduce the problem, or give a useful answer. If I get the feeling it's worth trying to get the OP to an answer, I will urge the OP to shorten the question and include additional code. If the problem is interesting enough, I may try to pinpoint the crux of the question and write a short version which addresses the problem. In this case the answer is almost invariably complete code (all the way from
#include to final
case 5 complete code with a bug
I will often answer in two parts. In part 1 I will focus on the problem area, with one or two lines of code showing what was going wrong; and then I may post the entire code again, with the bugs fixed. This shortens the cycle of "where do I put these lines" etc.
case 6 interesting question that doesn't directly involve code.
I came across a really interesting question from NPE a few months ago. It was short, and didn't directly involve code, although it did relate directly to programming / bit manipulation. I found myself writing a lengthy answer, that kept being modified as people were commenting / posting other answers. The result was quite well received: Extracting bits with a single multiplication
Based on the above rules of thumb, I think the answer to your question is something like this:
1) No it is never "harmful" to write a complete code. When someone asks for help, and they get it, they are in no position to complain "hey that's more than I wanted to know. I wanted to try this for myself!" If that is how they feel, they should state so explicitly in their question (and sometimes they do; in that case I always honor their request for a "hint rather than solution".)
2) Is it good/bad practice? As I said above, "it depends". I err on the side of completeness; people learn from examples (and if my example is not good, comments will soon fix that; I will then take those comments into account to improve the answer)
3) Is there a standard? I don't think so - although I believe my rules of thumb are roughly the same as those that others use.
For further reading, you might want to read what Jon Skeet said in his blog, (to paraphrase: complete code is good) or refer to this earlier similar question, and its answers.