Not that long ago I thought of a trivial style change that I rather like. Instead of using strict at the top of my modules, and then having to declare vars like @ISA and @EXPORT_OK for things that I only want in my header, put strict at the end of my header section and drop the declaration.

So where I used to write: 

package Foo;
use strict;
use vars qw(@ISA @EXPORT_OK);
@ISA = 'Bar';
@EXPORT_OK = qw(great stuff);

# etc

[download]
I now write: 
package Foo;
@ISA = 'Bar';
@EXPORT_OK = qw(great stuff);
use strict;

# etc

[download]
So are there any other useful style tips that people have lying around?

Replies are listed 'Best First'.
Re: Trivial style ideas
by Adam (Vicar) on Jan 23, 2001 at 06:51 UTC
    Actually, in 5.6 the way to do this is: 
    package Foo;
use strict;
use warnings FATAL => 'all'; # I hate warnings.
use Exporter;
our @ISA = qw( parent );
our @EXPORT_OK = qw( export these );
our $VERSION = "1.0";
#etc

    [download]
[reply]
[d/l]
[reply]
Re: Trivial style ideas
by bsb (Priest) on Jan 23, 2001 at 06:35 UTC
    In the same vein, I've put $^W=1 after my uses instead of -w to avoid warnings from various naughty modules.

    It's not something I'd want to include in a my style though.

    Brad

[reply]
[d/l]
[select]
      You could even be English-like about it and put use warnings instead. Larry actually recommends this because allows for more precise control over where you want to have warnings on or off in your programs.
[reply]
[d/l]
Re: Trivial style ideas
by japhy (Canon) on Jan 23, 2001 at 06:37 UTC
    I don't use it in production code where someone else might need to maintain my code, but when I'm lazy, I define superfluous variables when assigning from @_: 
    foo(1,2,3);

sub foo {
  my ($x,$y,$z,@sorted,$stdev) = @_;
  # ...
}

    [download]
    That's probably a no-no, though. ;)

    japhy -- Perl and Regex Hacker
[reply]
[d/l]
Re: Trivial style ideas
by dkubb (Deacon) on Jan 24, 2001 at 14:10 UTC

    When I code, I try to make perl as hard on myself as possible, in order to catch bugs early. This is one reason why I, and alot of other people always use strict and -w. I find that when you code consistently in this environment, the amount of errors you produce goes down, as you slowly change your style to be cleaner.

    One thing I do is put this at the top of all my code:

    #!/usr/bin/perl -w

BEGIN {
  use strict;                   #Always..
  use Carp qw(verbose confess); #die verbosely, with stacktraces
  $SIG{__WARN__} = \&confess;   #die, on warnings
}

    [download]

    The main reason behind this is to make sure that there are no uninitialized value warnings, among other things, or else the program won't function at all. I find it forces me to use defined and exists as well before accessing values.

    Also, by putting it inside the BEGIN block, I am ensuring it will happen before any other modules load or any other code is executed.

    Does anyone think this is going too far, or that it could cause problems? If not, does anyone have any other general suggestions on how to make perl harder on myself?

    Update: I have taken tilly's advice, and removed the code, and put it outside of a BEGIN block:

    #!/usr/bin/perl -w

use strict;
use Carp qw(verbose confess);
$SIG{__WARN__} = \&confess;

    [download]

    I still prefer to set the warn signal handler to confess, because I want my programs to die when modules or the code itself has unitilialized values or other warnings inside it. I find that it forces me not to ignore small or large problems, as a broken program/module will get fixed before an annoying one. (And you never know when that annoying program could be causing 10x the amount of time to fix than if it was done when the annoyances first started).

[reply]
[d/l]
[select]
      Putting strict inside the BEGIN block keeps it from being seen for the whole module. Since use already happens immediately upon parsing the command, there is likewise no win for putting Carp inside the BEGIN block. As for turning warnings into dies, you could inline it like you are doing or create a small pragmatic module for it.

      One problem though. Warnings are added from time to time, so if you inline it there is a real possibility that a future change could hose large portions of your programs. Putting it in the module leaves you just as strict now, but with room to avoid a bad upgrade later. :-)

[reply]

Back to Meditations