in reply to Re: Things every perl programmer should know?
in thread Things every perl programmer should know?

use strict;
use warnings;

[download]
are often missing from programs that I see.

Careful you can get shot down in flames for that sort of talk.

Understanding why warnings and strict are good, and why they shouldn't be necessary in deployed code is something all new Perl programmers should learn. Unfortunately not all trainers and/or Perl gurus agree with that statement.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbie
Birmingham Perl Mongers
Web Site: http://birmingham.pm.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Replies are listed 'Best First'.
(jeffa) 3Re: Things every perl programmer should know?
by jeffa (Bishop) on Jun 04, 2003 at 20:10 UTC
    Actually ... chanting: 
    use strict;
use warnings;

    [download]
    in this community earns elevation via XP. But you do raise very good points, and seeing that you have been programming longer than myself, i realize that you are speaking straight from the "real world" gut. However, i would change "something all new Perl programmers should learn" to "something all new Perl programmers will eventually have to deal with". (as i didn't with one nameless company - instead i left.)

    The difference is that i would rather see advice to use strict and warnings than not. The fact that this doesn't happen as often as it should in the real world (let's face it - software design is hard!) doesn't mean that a new Perl programmer shouldn't excercise good practices now before they become ... tainted. Teach 'em the rules now, let 'em break the rules after the learn them. And Perl is all about breaking rules. ;)

    Besides, not all companies suffer from the "don't look back" syndrom that seems to accompany leaving strict and warnings out of production code ... i happened to work for two that used strict and warnings in production, as well as CVS religiously and Use Cases regularly. Maybe this wasn't necessary, but we didn't waste time tracking down and fixing obscure bugs either. ;)

    UPDATE:
    I should mention that the one place i don't use strict and warnings is when i write one-liners. My logic is that one-liners are true throw away scripts, and if you need strict and warnings, then it probably shouldn't be a one-liner. 
    perl -MCGI=foo -le"print foo{bar=>baz}=>qux"

    [download]

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
[select]
      Teach 'em the rules now, let 'em break the rules after the learn them

      That was my point on particular mailing list. There are far too many new programmers, not just in Perl, that have never been taught good programming. In Perl scripts using warnings and strict helps you in learning some good Perl programming practices.

      When writing C programs, I always used 'lint' before compiling and to me warnings and strict are the equivalent. It has taken time, but most Perl programmers I've worked with have gotten used to adding -w/use strict without thinking. In a company I used to work for, they had to port a badly written application to mod_perl. It took several months. The app that I was working on took a couple of weeks to be mod_perl compliant. They have since seen the light :)

      Another thing every Perl programmer should be taught is Testing. Its amazing how often the Test:: modules can keep you sane, when all else is driving you nuts with fustration.

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Barbie
      Birmingham Perl Mongers
      Web Site: http://birmingham.pm.org/
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[reply]
Re: Re: Re: Things every perl programmer should know?
by neilwatson (Priest) on Jun 04, 2003 at 17:53 UTC
    You make a good point. However, when I see code without a single my statement I know strict and warnings have not been used.

    Neil Watson
    watson-wilson.ca

[reply]
Re3: Things every perl programmer should know?
by dragonchild (Archbishop) on Jun 25, 2003 at 18:08 UTC
    Removing strict/warnings from deployed code ... I'm of two minds on this one. On the one hand, if it's deployed, you should be able to trust it. (I am, of course, speaking mostly tongue-in-cheek.)

    But, warnings and strict, coupled with good logging, will catch a ton of run-time errors, like undefined objects being used and the like.

    (Though, good programming practices and code reviews will catch 99% of those, anyways. I can't believe the amount of code that's just slapped together, especially in Perl. At my current position, I'm having to rewrite my customers' code cause my systems can't depend on their dreck.)

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]

In Section Meditations