A while ago, I was writing a large script with a lot of data in a BEGIN block. I forget why.
But it was late in the morning and, of course, some part of the script wasn't working right, so I wrote a quick debugging routine using Data::Dumper that dumped some of the values in the BEGIN block.
When I came back to it the next day, it was entirely incomprehensible, so I boiled it down to the following code:
#!/usr/bin/perl
use warnings;
use strict;
use constant DEBUG => not undef;
use Data::Dumper;
BEGIN {
my ($a, $b, $c) = (1, 2, 3);
my $deb;
if (DEBUG) {
$deb = sub {
print Data::Dumper->Dump([$a, $b, $c], [qw/a b c/]);
};
} else {
$deb = sub {
warn "Debugging not enabled!\n";
}
}
sub debug { &$deb }
}
The warn is there for when I removed the debugging information.
I would really like to know what I was thinking when I wrote this...
All you are doing by putting this code in a BEGIN block is making sure it runs before anything else, but I do not see anything in it that necessarily has to be in a BEGIN block. You can have it at the top of the code and it would run the same.
Your debug sub will print the same original values for $a, $b and $c. If you want to print current values, you should be passing the values to the debug sub (and change it to accept the passed values, it is best not to use globals either).
Did this accomplish what you wanted in your script?
-imran
Oh, no, this is a stripped-down version. The original code had several subroutines that needed initialization with lots of variables. This is just the interesting (that is, weird) part.
At university, a professor once told us also to comment when, why and in what mood we wrote some code, e.g
# 11.11.2004, late night # replaced global filehandles with lexical ones # after having drunk eight beers
I wrote some amazing code when I was drunk,
and debugged some terrible code when I was sober :-)
Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"
# code to mimic uniq(1)
# mode: divine
my @result = do {
my %counter;
grep ++$counter{$_} == 2, @input;
};
# mode: tired
for (@input) {
$multiples{$_}++;
}
for keys( %multiples ) {
print "$_\n" if (--$multiples{$_});
}
(And yes, both example stolen from [id://205137], and I mean absolutly nothing with the different modes.)
And when refactoring this code, a mode that suggest that the programmer was tired, drunk or thought him-/herself being [id://9073] is prime candidates for a rewrite.
That's actually a good idea. I think I might just start doing that.
When I came back to it the next day, it was entirely incomprehensible, ...Ahemm. I have a slight feeling you find coding under the influence informative ;-)
I would really like to know what I was thinking when I wrote this...
holli, /regexed monk/
The really sad thing is that unless my air conditioner is trying to kill me, I wasn't under the influence of anything. I think it was a rather bad case of looking at the same piece of code for far too long.
My guess is that the extra bit of code (warn "Debugging not enabled!\n";) comes from some point where you wanted to check which branch you had followed. In the middle of all of the other stuff you cut out, you were debugging your debugging code.
brian d foy
Subscribe to The Perl Review
Something like that. It was more "Let's make sure I take out all the debugging print statements before this code leaves my sight" than anything else.