Re^3: Choosing a log level

in reply to Re^2: Choosing a log level
in thread Choosing a log level

All I can add is that I do not consider the logging of a program's input parameters and other external inputs (env. vars etc.) as "cutesy informational messages"; as they are crucial to reproducing failing runs.

I do consider the logging of subroutine inputs as "cutesy", as they (given access to the program's inputs) are reproducible, on demand, driven by need, at runtime when debugging.

Having worked on systems that used extensive logging of every subroutine, function and method parameters, along with every detail of the programs action that the programmer thought might be useful when debugging, and having had to wade through gigabyte after gigabyte of mostly meaningless and always reproducible logs trying to work out where things went wrong, I have a strong aversion to the cutesy, guessed-it-might-be-useful kind of logging.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^3: Choosing a log level

Replies are listed 'Best First'.
Re^4: Choosing a log level by Your Mother (Archbishop) on Mar 30, 2017 at 20:43 UTC
I understand your aversion. I share it. The point of multiple log levels is to afford turning off the lesser, super-verbose logging but have the easy option to bring up more, maybe the whole enchilada, when a bug/issue eludes casual debugging. In production, I don’t send anything below FATAL and ERROR to the logs.	[reply]
Re^5: Choosing a log level by BrowserUk (Patriarch) on Mar 30, 2017 at 21:53 UTC
The point of multiple log levels is to afford turning off the lesser, super-verbose logging Hm. We'll have to agree to differ I think. That still means that the source code is cluttered with lots of junk who's only function is better achieved using line(number) tracing and/or temporary print statements. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^6: Choosing a log level by Discipulus (Canon) on Mar 31, 2017 at 08:33 UTC
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.	[reply] [d/l] [select]
Re^7: Choosing a log level by BrowserUk (Patriarch) on Mar 31, 2017 at 13:05 UTC
Re^4: Choosing a log level by SuicideJunkie (Vicar) on Mar 31, 2017 at 19:52 UTC
I suspect we agree on this, and the difference in in the perspective: Putting Garbage in the INFO, vs the INFO being full of Garbage. INFO would be useful if you only put useful info in. The "cutesy" things which are nominally reproducible given the program's inputs, IMO, should be strictly at DEBUG level and are only useful when you haven't done enough work on the code yet to predict the behaviour with confidence. I usually have those as simple console printing, and then outright delete them when I'm done the first draft of the code and have settled on data structures and variable names. A small few may stick around to serve as progress bars, but those strings end in \r instead of \n so they aren't spammy.	[reply]
Re^5: Choosing a log level by BrowserUk (Patriarch) on Mar 31, 2017 at 20:14 UTC
I suspect we agree on this, and the difference in in the perspective: Yes. I think we do. I usually have those as simple console printing, and then outright delete them when I'm done the first draft of the code and have settled on data structures and variable names. A small few may stick around to serve as progress bars, but those strings end in \r instead of \n so they aren't spammy. I also tend to delete debug trace when I'm done with it. (And have been known to leave a few sitting around as a "somethings happening" indicator.) With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]

In Section Seekers of Perl Wisdom