in reply to deleteing array elements I get mad!!

This is one of those (many) places where use strict would have told you what the problem is.

What you're doing is effectively this:

use strict; use warnings; my $arr_ref = [1, 2, 3]; delete $arr_ref[0];

And running that gives the error:

Global symbol "@arr_ref" requires explicit package name

You have an array reference in $cashflow, but you're treating it as if it's an array.

--
<http://dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Replies are listed 'Best First'.
Re^2: deleteing array elements I get mad!!
by kurreburre (Acolyte) on Oct 03, 2006 at 12:20 UTC
    Thanks Well usually I use strict. But now I have to finalize code that someone else started, and worked with for 3 month, and I have to finalize by tomorrow. The code base is so big so I have to pick bits and pieces to save time, and these bits and pices are clutterd bit global vars, loading of vars with requre (var are set in different files), so I just had to turn strict off to able to continue. Cheers Pär
      I know you're working on a deadline (and I'll go in to that later) but that would be the wrong way around. The absolutely very first thing I recommend when inheriting bad code (and we have all had to do it) is getting the source to compile under use strict;.

      As for the deadline (arbitrariness aside) getting code running under use strict; will take less time than you think. Really it will, no matter how bad the code is. Most importantly, it almost assuredly save you time (short term and long term).

      1. The obvious reason: You will have better code to read and debug.
      2. The not so obvious reason which will save you the most time: You will find the little tiny bugs that no one ever thinks to look for right away - instead of days, weeks, ... later when it takes you most of a day to find that one last irritating bug that everyone is getting bent out of shape about.

      Seriously, it sounds like waste of time, but it isn't.
      You may think, 'This code is worse than anyone has seen, so adding use strict will take longer than anyone can understand.' but trust me I have seen worse code and using strict is more important and saves more time, the worse the code is.



      grep
      One dead unjugged rabbit fish later