Opps! I did it again. Had an opinion that is. I should probably not answer this, but it's simply too provocative.

In reverse order:

Another example is how to set up some of Matt Wright's scripts.

I would tell them that I cannot help them with that, but that I had heard that Matt's script are notoriously difficult and dangerous to use and suggest that they might find it easier to visit NMS instead.

Read http://perl.plover.com/varvarname.html and follow the links to see one example of a common question that should not be blithely answered as asked.

First Perl did not have hashes references (*thanks jdporter) for many years, and symbolic references where used a lot. Done properly, it can be an amazingly powerful and useful feature.

Many of perl's native abilities can be be dangerous if used incorrectly, or as in the case cited by MJD in your reference, used without proper forethought for the consequences.

Finally, I never advocated doing anything blithely. I think said,

• You move on dodgey ground when you assume information that isn't in the question
• On even dodgier ground and risk offending or being offended when you make judgements on the questioners skill levels, background or motives based on one question.
• Can soften the blow of the suggestion that the questioner is going in the wrong direction by giving a little context or a link explaining why. MJD's piece makes a fine example of this.

I would usually say something to the effect of:

Are you sure that's what you want to do? If your sure, read Perlref and by the time you've done so, you will probably understand how to do it, but more importantly why you almost certainly don't want to. Beyond that, if you'd care to explain a little more about why you want to do this, someone may be able to show you a better way to acheive your goals.

I realise some would read that as patronising, but if they do, that's their problem not mine.

What if the person is asking for advice on how to do something that will be really bad for their code-base, which you know will be bad for their code-base (eg obvious insecurities, sources of major bugs)? What then?

First off, I don't know. I can hazard a good guess, but they know better than I and as you point out, it is their codebase

What if someone asks for advice on how to commit suicide? Do you answer that?

After much typing and deleting, I've decided to pretend that pair of questions was not asked. If you want to have a serious and deep debate on a very awkward subject, I'm sure we can find somewhere more suited to that than PerlMonks.

And I guess that is a lesson in its self. Noone is forcing us to answer either way. Likewise, if I choose to give what I think is 'good advice' and it is rejected, I tried. It's enough. Perl doesn't enforce good practice, hence warnings, and strictures are optional. Personally, I'd probably invert the default, but I'd still make it optional.

Updated to close UL tag and correct brain fart.