How not to write subroutines

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 }
}
[download]

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...

"If you go on with this nuclear arms race, all you are going to do is make the rubble bounce" -- Winston Churchill

Comment on How not to write subroutines Download Code

Replies are listed 'Best First'.
Re: How not to write subroutines by strat (Canon) on Jan 15, 2006 at 10:38 UTC
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` [download] 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"	[reply] [d/l]
Re^2: How not to write subroutines by nacka (Friar) on Jan 15, 2006 at 13:38 UTC
I kind of liked the idea of putting in the mood of the programmer in comments. `# code to mimic uniq(1)` [download] `# mode: divine my @result = do { my %counter; grep ++$counter{$_} == 2, @input; };` [download] `# mode: tired for (@input) { $multiples{$_}++; } for keys( %multiples ) { print "$_\n" if (--$multiples{$_}); }` [download] (And yes, both example stolen from Get All Duplicated Elements in an Array (Once, without shifting), 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 merlyn is prime candidates for a rewrite.	[reply] [d/l] [select]
Re^3: How not to write subroutines by gustavderdrache (Acolyte) on Jan 15, 2006 at 15:38 UTC
That's actually a good idea. I think I might just start doing that. "If you go on with this nuclear arms race, all you are going to do is make the rubble bounce" -- Winston Churchill	[reply]
Re: How not to write subroutines by brian_d_foy (Abbot) on Jan 15, 2006 at 17:18 UTC
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 <brian@stonehenge.com> Subscribe to The Perl Review	[reply] [d/l]
Re^2: How not to write subroutines by gustavderdrache (Acolyte) on Jan 15, 2006 at 19:38 UTC
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. "If you go on with this nuclear arms race, all you are going to do is make the rubble bounce" -- Winston Churchill	[reply]
Re: How not to write subroutines by CountOrlok (Friar) on Jan 15, 2006 at 07:48 UTC
I have no idea what you were thinking. 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	[reply]
Re^2: How not to write subroutines by gustavderdrache (Acolyte) on Jan 15, 2006 at 15:24 UTC
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. "If you go on with this nuclear arms race, all you are going to do is make the rubble bounce" -- Winston Churchill	[reply]
Re: How not to write subroutines by holli (Abbot) on Jan 15, 2006 at 15:53 UTC
When I came back to it the next day, it was entirely incomprehensible, ... I would really like to know what I was thinking when I wrote this... Ahemm. I have a slight feeling you find coding under the influence informative ;-) holli, /regexed monk/	[reply] [d/l]
Re^2: How not to write subroutines by gustavderdrache (Acolyte) on Jan 15, 2006 at 16:08 UTC
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. "If you go on with this nuclear arms race, all you are going to do is make the rubble bounce" -- Winston Churchill	[reply]