Logging has the same format especially timestamp for all components in the system.
Originating source of each line of logging can be easily determined from the line of logging.
Logged info must be designed to assist support engineers as well as developers (best achieved by separate or concatenated logging for each audience type
The difference between the line of logging and further information and/or guilty data needs to be clear from the logging syntax you choose.
and whatever else other monks might notice (it is also getting late for me).
I would also advise using a namespace that is less mistakable with the mathematical concept of log, i.e. use Logging instead of log. My first thought was that your module had something to do with logs to base 4 which I suggest is not so stupid given that logs to base 8 are important in devORops - a profession I recently accidentally adopted which might well be on the up.
upd+ ok you can get away with some diversity and nonconformity but you cannot ignore what the overall objective of logging is (support/maintenace of an application system) to the extent you seem to have done so in the narrowness of your scope.
upd+ if you do design it for more general use, you'd want to make a callable API of it and have your Perl module also call that.
One world, one people
In reply to Re: Evaluation of my CPAN module
by anonymized user 468275
in thread Evaluation of my CPAN module
by nysus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |