Logging is a form of code duplication. Code duplication is a well-known code smell. Tightly coupling systems to particular logging implementations by invoking the logger liberally throughout an application makes replacing the logger difficult in practice. Ideally, switching logger implementations would take no more than revising a single source file and creating a new configuration for the replacement library.
Why is it desirable to switch logging libraries easily?
Perhaps the deeper question is: Why is loose coupling desirable? Tight coupling reduces flexibility and re-usability of code, making changes more difficult. Changing one object in a tightly-coupled application often requires changes to other objects, which increases maintenance costs.
To your question, what if there was a remotely exploitable bug that was discovered in the logger, and the product was about to ship? It’s easier to change 10 lines of code than 1,000.
Let’s step back. What is logging? According to Wikipedia, logging assists users and developers by recording events. What I advocate for is making those events … events!
Consider the following example:
final Logger logger = new Logger();
logger.log( "Application starting" );
// ... later ...
logger.log( "Application terminating" );
Instead, for virtually the same amount of effort, we could write:
ApplicationStartedEvent.publish();
// ... later ...
ApplicationStoppedEvent.publish();
An event-based model offers the following benefits:
Integration testing can rely on events, instead of brittle pause times.
Third-party applications can subscribe to the events, even across the network.
Third-party event monitoring can be cross-language and cross-platform.
Internationalization applied to (user-facing) log messages.
Standardization of log message formats, which allows for correlative searches and filtering.
DATE TIME [APP] [MODULE] [CLASS]: [ID] event name | var1: value1 | var2: value2
Easily assign unique identifiers to events, along with remediation described in product guides.
Event processing in multiple ways (on a web page, to a log file, into a database, push to D-Bus).
Develop new functionality based on events, without having to change existing source code.
Fine-control over periodicity of logging, duplication filters, and message tallies.
Further, events can occur on a separate thread and it’s trivial to change the log message to include a timestamp for when the event was triggered (as opposed to when the event was logged).
Why is it not desirable to isolate logging to a single location in the code base?
Perhaps the deeper question is: Why is loose coupling desirable?
Spending time and cognitive energy to decouple things for no point is a bad trade. Loose coupling makes things harder to understand. It’s still useful in many situations, but you shouldn’t treat it like a blind good, because it’s not.
Why is it not desirable to isolate logging to a single location in the code base?
Spending effort/code on changes that you will never make in reality is generally not desirable. It’s like abstracting away your database. Why? Are you really going to ever switch databases?
To your question, what if there was a remotely exploitable bug that was discovered in the logger, and the product was about to ship? It’s easier to change 10 lines of code than 1,000.
No one resolved this by switching logging libraries. They patched log4j and upgraded
Relevant ongoing discussion regarding supporting structured leveled logging in the Go standard library: https://github.com/golang/go/discussions/54763
I use Zerolog in my project. Works great!
Logging is a form of code duplication. Code duplication is a well-known code smell. Tightly coupling systems to particular logging implementations by invoking the logger liberally throughout an application makes replacing the logger difficult in practice. Ideally, switching logger implementations would take no more than revising a single source file and creating a new configuration for the replacement library.
See also:
Why is it desirable to switch logging libraries easily?
Perhaps the deeper question is: Why is loose coupling desirable? Tight coupling reduces flexibility and re-usability of code, making changes more difficult. Changing one object in a tightly-coupled application often requires changes to other objects, which increases maintenance costs.
To your question, what if there was a remotely exploitable bug that was discovered in the logger, and the product was about to ship? It’s easier to change 10 lines of code than 1,000.
Let’s step back. What is logging? According to Wikipedia, logging assists users and developers by recording events. What I advocate for is making those events … events!
Consider the following example:
Instead, for virtually the same amount of effort, we could write:
An event-based model offers the following benefits:
Further, events can occur on a separate thread and it’s trivial to change the log message to include a timestamp for when the event was triggered (as opposed to when the event was logged).
Why is it not desirable to isolate logging to a single location in the code base?
Spending time and cognitive energy to decouple things for no point is a bad trade. Loose coupling makes things harder to understand. It’s still useful in many situations, but you shouldn’t treat it like a blind good, because it’s not.
Spending effort/code on changes that you will never make in reality is generally not desirable. It’s like abstracting away your database. Why? Are you really going to ever switch databases?
No one resolved this by switching logging libraries. They patched log4j and upgraded