Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Things every perl programmer should know?

by neilwatson (Curate)
on Jun 04, 2003 at 16:17 UTC ( #263045=note: print w/ replies, xml ) Need Help??


in reply to Things every perl programmer should know?

Although it seems obvious to most perlmonks,

use strict; use warnings;
are often missing from programs that I see. Perl newbies need to know that using this modules will help create clean portable code faster than without them.

In the bigger picture I think perl users (indeed all programmers) need to better educate themselves on network and system security. Learn how the code you write can affect others. The server is not a island. What you do cause others to have a very bad day.

Neil Watson
watson-wilson.ca


Comment on Re: Things every perl programmer should know?
Download Code
Re: Re: Things every perl programmer should know?
by barbie (Deacon) on Jun 04, 2003 at 17:44 UTC
    use strict; use warnings;
    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/
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      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

      Actually ... chanting:
      use strict; use warnings;
      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"

      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)
      
        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/
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      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.

Re: Re: Things every perl programmer should know?
by Jenda (Abbot) on Jun 04, 2003 at 19:33 UTC
    I'd use
    use strict; use warnings; no warnings 'uninitialized';
    myself. I seriously dislike having to write code like
    if (defined $foo and $foo) { ...

    Update on Jun 05, 2003: I do not remember the last time I got a "Variable is used once" warning. Maybe I was just lucky :-)

    Jenda
    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
       -- Rick Osborne

    Edit by castaway: Closed small tag in signature

      For me, it's:
      use strict; use warnings; no warnings 'once';
      because that sodding warning has never caught anything for me that strict wouldn't have trapped sooner. The kicker is that fixing it requires jumping through very silly hoops to make it go away. ($foo = $foo = 1; anyone?) As for uninitialized - well, I don't get a warning on
      if ($foo) { ... }
      I admit it's sometimes a little awkward to code around the uninitialized warning, but usually something like adding a || 0 or || '' or such does the trick just fine. And that kind of thing isn't silly, in fact I think it's clearer in intent in that I document via code that I explicitly expect undefs there.

      Makeshifts last the longest.

        no warnings 'once'; because that sodding warning has never caught anything for me that strict wouldn't have trapped sooner. The kicker is that fixing it requires jumping through very silly hoops to make it go away.

        I find that error message very useful. It's not just catching spelling errors, which strict does indeed do better, but it's also catching variables that you really did use once. Variables used once are useless.

        If you have a variable that is used only once, then why use that variable? You're throwing away its value if it has one, and there's a variable declared that you don't use. "Variable used only once" actually means "Hey, you forgot to remove a line during your lastmost recent refactoring" or at least "You're throwing away valuable resources". :)

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://263045]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (10)
As of 2014-11-22 16:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (123 votes), past polls