5 ms·

> Making logs during development also forces developers to make a conscious effort of finding a balance of what and when to log something, create proper debug l

> Making logs during development also forces developers to make a conscious effort of finding a balance of what and when to log something, create proper debug levels not to overwhelm the logs, while still providing some useful information... The need for this balance is why I don't completely agree with the article. If I'm debugging something with log messages, I put way more detail into it than I want to see in production even at LogLevel.DEBUG.

mike_hock 5y ago
Plus, I'm adding more and more as I box in the problem. If I left that in I'd have an extreme level of detail around an aspect of the program that's very unlikely to have a bug because it's been thoroughly analyzed and fixed while being blind to everything else (except the parts that have received similar attention). Maybe I'm just bad at it.
throwaway894345 5y ago
I don't know that there's an easy solution to this problem, but what I've seen Kubernetes and other Google-derived projects do is replace standard log levels with an increasing series of integers so you can log in increasing detail. This seems a little arbitrary (one developer's 8 might be another developer's 14 or something) but at least you can easily ask for increasingly more detail until you get what you need without noise-by-default.
- dmurray 5y ago
  The increased detail also clutters the source, though. As I write this I realise that the "right" solution is that my IDE also folds away log calls of below some settable priority... Then I need a linter to prevent any code with side effects from running in a log line... Then I need to work in a language where that kind of static analysis is definitely possible... Maybe it's not so simple.
  - rhizome 5y ago
    Create a logging method/function, llog() or something, with named parameters and whatnot.
- kevin_thibedeau 5y ago
  This just creates a festering problem because devs are given too much freedom. A better solution is just two levels, basic and verbose, with subsystem feature flags you can control to prevent verbose from being a fire hose.
  - verdagon 5y ago
    That sounds promising. Ever done it this way? Howd it turn out?
wruza 5y ago
If I'm debugging something with log messages, I put way more detail into it than I want to see in production even at LogLevel.DEBUG. I mean, there is LogLevel.TRACE when you need it. For those not familiar, this level is exactly for “I’m writing new buggy code where anything can go wrong so stupidest details matter”-time. You can use it to separate normal debug logging like “request body is {…}” from sandbox logging like “loop counter just became [object Object]”.

mike_hock 5y ago

Plus, I'm adding more and more as I box in the problem. If I left that in I'd have an extreme level of detail around an aspect of the program that's very unlikely to have a bug because it's been thoroughly analyzed and fixed while being blind to everything else (except the parts that have received similar attention). Maybe I'm just bad at it.

throwaway894345 5y ago

I don't know that there's an easy solution to this problem, but what I've seen Kubernetes and other Google-derived projects do is replace standard log levels with an increasing series of integers so you can log in increasing detail. This seems a little arbitrary (one developer's 8 might be another developer's 14 or something) but at least you can easily ask for increasingly more detail until you get what you need without noise-by-default.

dmurray 5y ago
The increased detail also clutters the source, though. As I write this I realise that the "right" solution is that my IDE also folds away log calls of below some settable priority... Then I need a linter to prevent any code with side effects from running in a log line... Then I need to work in a language where that kind of static analysis is definitely possible... Maybe it's not so simple.
- rhizome 5y ago
  Create a logging method/function, llog() or something, with named parameters and whatnot.
kevin_thibedeau 5y ago
This just creates a festering problem because devs are given too much freedom. A better solution is just two levels, basic and verbose, with subsystem feature flags you can control to prevent verbose from being a fire hose.
- verdagon 5y ago
  That sounds promising. Ever done it this way? Howd it turn out?

wruza 5y ago

If I'm debugging something with log messages, I put way more detail into it than I want to see in production even at LogLevel.DEBUG. I mean, there is LogLevel.TRACE when you need it. For those not familiar, this level is exactly for “I’m writing new buggy code where anything can go wrong so stupidest details matter”-time. You can use it to separate normal debug logging like “request body is {…}” from sandbox logging like “loop counter just became [object Object]”.