[Mastering-perl] Debugging, Profiling, and Cleaning Up Code

[Florian Merges]

2006/10/11, Adrian Howard <adrianh at quietstars.com>:
>
> On 7 Oct 2006, at 11:46, brian d foy wrote:
> [snip]
> > I've added a bunch of stuff to the Debugging chapter:
> >
> > http://www.pair.com/~comdog/mastering_perl/Chapters/04.debugger.html
>
> I kinda expected the print/warn section to move on to a discussion of
> logging modules, does that happen elsewhere? If not that would be
> trez useful. Pretty much everybody I encounter has some mastery of
> the print-style of debugging. Far fewer have any idea how to do
> logging well.
>
> I'd stick in a warning about the problems with $SIG{ __DIE__ } and
> $SIG{ __WARN__ } and persistent environments like mod_perl.
>
> fatalsToBrowsers - I'm in the "don't do this on live boxes" school
> since if you do have a bug it might reveal bad things to evil folk.
> Maybe worth warning folk of potential dangers?


This is like the warnings things... but I also agree that the errors should
go dumped to a log and not to the client. Of course showing an error
message, but not a program error dump...


> And I think I'm mostly done with the Profiling chapter:
> >
> > http://www.pair.com/~comdog/mastering_perl/Chapters/06.profiling.html
>
> I'd appreciate a little more emphasis on the dangers of unnecessary
> optimisation near the start. I've seen people misuse Devel::SmallProf
> - spending days agonising over two or three "slow" lines that make no
> damn difference to anything.
>
> With Devel::Cover - might be worth mentioning Module::Build's built
> in support for ./Build testcover.
>
> POD coverage modules?
>
> Memory profiling? - Devel::Size, Devel::Size::Report, Devel::DumpSizes ?



Think givin' a mention to Devel::Size is good, sometimes I see myself using
it to get an idea how much mem a bunch of objects will need...


> Next up is the Cleaning Up Code chapter, which need the last half
> > written. That's all Perl::Critic stuff:
> >
> > http://www.pair.com/~comdog/mastering_perl/Chapters/
> > 07.cleaning_up_code.html
>
> Nice apart from:
>
> "In general, I recommend turning off warnings once a program is in
> production. Turn on warnings when you need to test or debug the
> program, but after that, you don't need them. The warnings will just
> fill up log files."


This happen, when your code is not clean, hehe }:-), and for thinks that
should be so, you can turn warnings off selectively...

which I consider.... odd advice :-) The point of log files is to spot
> problems. Warnings are often indications of problems. That's why log
> files filling up with warnings is a /good/ thing. That way you can
> fix the problem!


Is said that the warnings should be turned off once before releasing, but
it's like allways, for a little program you do, where is not necessary to
have something optimized, it really doesn't care... and I think it's better
to have it one, 'cause so you don't have tu add or uncomment the stanza
everytime you do a little change...

Thinks about logging and so, modules like Log::Dispatch, and perl4j could
also be mentioned, I use Log::Dispatch a lot in bigger apps.


Cheers,
>
> Adrian



Kind regards,

Florian

_______________________________________________
> Mastering-perl mailing list
> Mastering-perl at theperlreview.com
> http://five.pairlist.net/mailman/listinfo/mastering-perl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://five.pairlist.net/pipermail/mastering-perl/attachments/20061011/0a6ebd80/attachment.html