This entry is somewhat in line with my previous journal entry on comments in code.
Way too often we are so busy we do not get our code completely prepped for production.
This mean commented-out code is not removed, code is not peer-reviewed and POD is not updated (if written at all).
I have other issues like lacking tests, documentation aso. but lets stick to the topic.
I would live to see a proper staging process and use of a staging platform, I looked up the word in my dictionary and it said (somewhat edited): stage |stāj| noun
*snip*
- each of two or more sections of a rocket or spacecraft that have their own engines and are jettisoned in turn when their propellant is exhausted.
*snip*
Man, this is exactly what I mean, throw away the parts you do not need. I would love if we could would just go over the code at least once and remove the debris of the development.
And next we go over the code and isolate all debugging and verbose logging so it
can be controlled using flags from a single point.
Other things we could do?
We can always adopt peer reviews when we get the time.
And next we go over the code and isolate all debugging and verbose logging so it can be controlled using flags from a single point.
Did you mean: Log::Log4perl
Re:Logging
jonasbn on 2008-01-29T08:28:33
Nah, more in the line of:
print STDERR "We are now in func2\n";
print STDERR "we got params:\n", Dumper \@params;
We have a lot of such code. I attempt only to inject
when really desperately debugging or atleast isolating it behind
if (DEBUG) {... } Re:Logging
Aristotle on 2008-01-29T09:13:11
That’s the point: with Log4perl, you can leave it in. You configure at runtime precisely which logging messages you’re interested in (yes, while the program runs – not just at startup).
Furthermore, if you worry about expensive computations in your logging statements, you can pass a closure instead of a string, which will be invoked only if that statement is enabled. The logger call still happens, so this is not as efficient as
if (DEBUG) {(which is completely optimised away at compile time if... } DEBUGis a false constant), but it's worlds more flexible and the remaining cost is usually negligible.Log4perl is great stuff.
Re:Logging
jonasbn on 2008-01-29T09:19:34
I utilize log4perl with the Workflow distribution, but not for work currently. I will investigate if we can make use of log4perl in this setup.
Thanks,Re:Logging
Aristotle on 2008-01-29T11:01:52
Ah, didn’t know you knew it already. A lot of people don’t, and logging is one of those things where it’s really really easy to understand and solve 30% of the problem, but it’s hard to imagine the whole problem and a lot of work to solve it well, so it’s common to get stuck at the 30% threshold.
I was stuck there too before I read an article about Log4perl. It really opened my eyes – I had been doing things in a pretty crappy way but it never occurred to me I could have better. So now whenever I see someone wringing their hands about log/debug statements, I tell them to look at Log4perl.
(After that article, I looked at other logging modules, because I wasn’t sure whether Log4perl is really that great or I just hadn’t seen any better before. Turns out it really is that great; only Log::Dispatch is close.)
Re:Logging
Alias on 2008-01-29T22:59:47
> if you worry about expensive computations in your logging statements, you can pass a closure instead of a string.
*Light Bulb Moment*
Oh wow, why did I never think of that before.
Re:Logging
jonasbn on 2008-01-30T08:27:52
Well I don't - I am just bothered by unnecessary logging in already crowded logs.
