P is for Practical | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Is obviously a matter of taste and it may vary a lot under different circumstances.
But i dont think source code is cluttered if you have a granulary defined set of logging levels. Infact you can have or a generalistic function that receive the loglevel as first argument as in mylog ("ERR","main DB is not available"); or many specialized subs that all inherit same behaviour from a generic one, resulting in something like: err ("auth failed"); Playing with prototypes (uch!) you can have a cleaner syntax like err "auth failed"; All these lines, in my opinion, do not make noise in the code; they help to clarify the code itself like comments and probably in a more precise way. Reviewing the code you can immediately know what (the programmer thinks is supposed to) happens if something is ok or is not ok. You also get an immediate perception about the severity of what happened. I ever work alone, no one inspect my code (outside PM) but i suspect that in cohoperative Perl team this is a big benefit. Such practice can incide on the program speed? I dont know but it seems difficult to me: if the loglevel is normally set on WARN on production the whole other calls to the logging sub end to be a bare return; that i suspect Perl optimize as nothing to do or comments/POD (just a guess).
L*
There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS. In reply to Re^6: Choosing a log level
by Discipulus
|
|