On 08.02.2021 10:09, Steven Haigh wrote:
On Sun, Feb 7, 2021 at 15:17, Chris wrote:
Just remember to always write clean code that resets variables after doing
tasks.
I'm a bit curious about this - whilst I'm still testing all this on a staging environment,
how can I tell if things can leak
That is a good sign – I would run with brutal at least once and see what it
throws up
We tend to ignore a couple of the warnings – one is postfix if/unless and the
other is multiline strings {we embed a lot of simple HTML templates in code and
it means I can make the HTML readable when rendered
On Mon, Feb 8, 2021 at 09:13, James Smith wrote:
Use perl-critic this will find most of the nasties that you have the
classic is:
Thanks for the tip! I have no idea how long I've been writing stuff in
perl - and I never knew of this!
I ran it with the -3 option - which I figure is a good mi
Use perl-critic this will find most of the nasties that you have the classic is:
my $var = {code} if {condition};
The my gets round perl strict, but $var doesn’t get updated if {condition}
isn’t met, so holds the variable from the last time round..
Better is
my $var = ‘’;
$var = {code} if {con
On Sun, Feb 7, 2021 at 15:17, Chris
wrote:
Just remember to always write clean code that resets variables after
doing tasks.
I'm a bit curious about this - whilst I'm still testing all this on a
staging environment, how can I tell if things can leak between runs?
Is coding to normal 'use st
I meant between requests in the same thread – it uses persistent connections
which are bad in a number of ways {e.g. fun with locking if you use it and your
script dies halfway through, keeps too many connections open and can block the
database, has issues with secure set ups {firewall between w
