From Novice to Adept: On Answers to Smart Questions

I see this often on PerlMonks. I haven't see it as often on the Perl Beginners Mailing List. I think some community differences explain this behavior.

I don't intend to answer the question of why (though that could be amusing; I find bleak amusement in certain PerlMonks threads that descend into several respondents flailing about to offer suggestions which they have obviously not tried because Perl does not work that way). I prefer to give advice for novices who want to ask questions and get useful answers.

I could recommend How to Ask Questions the Smart Way and leave it at that. You should skim that document. I know most novices won't read it in part or in full, but they should. Even so, that document doesn't answer an important question: how can I tell if the advice I've received is useful or a meaningless debate over brace placement that isn't worth my time?

There's one general rule: if you've asked a good question (per the linked document) and you've received at least one meaningful response which seems to answer your question, you can safely ignore the contents of responses which don't answer your question directly.

In other words, if anyone on PerlMonks says "I don't know, but you should always use strict and warnings," you can ignore the rest of the post.

If someone gives you an answer that seems reasonable and, after you test it locally, seems to do what you need and then offers some style advice, consider it.

If someone tells you that your entire approach is wrong and gives you an alternative which seems credible, you should consider the alternative enough to get a sense of its benefits and drawbacks. If this means posting a followup, that's fine too.

If more than one response suggests that your code is too difficult to debug without changing your style, consider it.

If every response suggests that you're doing something wrong, take that advice.

That's all well and good, but how do you tell whether approaches are matters of style or the difference between correct and incorrect behavior or maintainable or unmaintainable problems? You cheat. Run your program through Perl::Critic and see which, if any, severity level discusses the style issue. If the default, least strict severity suggests you have a style problem, address it now. If the most strict severity level is silent about your style problem, you can ignore it for now.

If the style issue is over brace placement or indentation or something P::C doesn't care about, compare your code with Perl::Tidy's reformatting and see which you find easier to read. Then ignore style discussions.

As for the rest, take advice where you can get it. A lot of experienced developers have a lot of practical experiences using and maintaining Perl programs for many years. They have written and maintained programs that solve a lot of problems. They've seen community idioms and common solutions wax and wane as community members discovered problems and new solutions and better abstractions. Don't walk away from that wealth of knowledge and advice in favor of a short-term solution. Yet also don't get confused that people care about long-term sustainability of programs and programmers; the kind of people who care about answering novice questions -- the kind of people you want to answer novice questions -- have some interest in seeing you avoid the rough spots they had to encounter the hard way.

Safety and correctness are concerns -- but P::C goes a long way to identify the most important antipatterns there. Ultimately the question of whether one construct is more readable than another depends on your preferences, the coding standards of your organization, your problem domain, and your experience and familiarity with the language and its idioms. The best thing you can do is train yourself to consider short- and long-term ideas. That's not easy, but fortunately many people answering novice questions will do so. Learn from them.