Re: Perlmonk's "best pratices" in the real world

[sauoq]

Uhm... use strict; and use warnings;... at least while developing. They will help you catch stupid bugs quicker, leaving you more time to write code or play games.

With everything else you mention, the answer is an old standby: it depends.

I've written many CGI programs without CGI.pm or an alternative like CGI::Simple but most of them have something in common: no user input. Or very simple user input like, say, a path component but no parameters. If I'm processing parameters, I'll use a module that has that has tested code to do it. I've never used CGI::Application.

Sometimes OOP makes sense and sometimes it doesn't. If you aren't comfortable with it and don't care to be, then it doesn't make sense. Simple as that. There's nothing you can do with OOP that you can't do without it, so don't fret over it. Use what you know.

As for templates, if you haven't found a place where you need them yet it's probably because you really haven't needed them. You'll know when you do. Same thing with placeholders. You'll start using them when something breaks because you didn't.

Sometimes you have to look past the specific suggestions to find the more general advice. Often that advice boils down to "don't do work you don't need to" or "don't shoot yourself in the foot." No one can really tell you what is best in your situation.

In the end, most of these are really issues of style. The details matter very little. There are as many ways to write code well as there are good coders. The fundamentals like consistent formatting, appropriate commenting, and rigorous testing are far more important than which of the many MTOWTDI that you choose.

But, you really should use strict; and use warnings;... :-)

[skx]

I know this is being pedantic, but I find that using strict after development is over and when code is "live" is usually the most useful.

Sure it's nice to have in development, but as much testing as I can do it's when stuff is live that I really want to see comprehensive, readable, error messages.

[sauoq]

I know this is being pedantic,

No, it isn't. It's merely being opinionated. This reply is pedantic...

According to Merriam-Webster, an appropriate definition of "pedantic" in this usage would be "of, relating to, or being a pedant." Its root is defined variously as one who makes a show of knowledge, one who is unimaginative or who unduly emphasizes minutiae in the presentation or use of knowledge, or a formalist or precisionist in teaching.

I find that using strict after development is over and when code is "live" is usually the most useful.

Most of the errors that strict provides are compile time errors. The exception is a runtime error when you use symbolic reference under strict 'refs'. So, unless you have evals (the expression form) or are using /ee on regexes and propogating the errors in $@, strict is limited in its usefulness in "live" code.

That doesn't mean I don't leave it on; I generally do. But its benefits are definitely more pronounced during development. Besides, if your "live" code is generating errors because of strict checking, then development isn't exactly "over", now is it?

Sure it's nice to have in development, but as much testing as I can do it's when stuff is live that I really want to see comprehensive, readable, error messages.

Using strict doesn't change the quality of the error messages you get. Perhaps you are thinking about use diagnostics? Strict checking causes more conditions (the ones you usually want to avoid) to be reported as errors in the first place. Enabling warnings does exactly the same thing but results in warnings rather than errors.

BTW, if you aren't testing before the code is "live", then you are testing while it is live. Maybe what you are really saying is that you find these pragmas most useful during testing...

[jpfarmer]

As far as use warnings; goes, I normally remove it from non-critical production code that I don't actively use. I'll leave use strict; in forever, but I remove use warnings; because it can cause warning messages to pop up in perfectly valid code when versions of Perl change (and definations of what is warnable change with it). It makes users nervous, and normally doesn't affect much.

I picked this practice up from Learning Perl, 3rd ed. The passage I took it from:

"Of course, warnings are generally meant for programmers, not for end-users. If the warning won't be seen by a programmer, it probably won't do any good. And warnings won't change the behavior of your program, except that now it will emit gripes once in a while. If you get a warning message you don't understand, look for its explanation in the perldiag manpage.

Warnings change from one version of Perl to the next. This may mean that your well-tuned program runs silently when warnings are on today, but not when it's used with a newer (or older) version of Perl. ... But you shouldn't count on the text or behavior of any warning staying exactly the same in future Perl releases. "