Logging is a code-smell. Some logging is needed, naturally. What you want is a good tracing system, like DTrace and the function boundary and user-space static probe providers.
In Java that would be BTrace.
Logging as a code smell
21–30 of 54 posts
Re: Logging as a code smell
#22I remember using the SciTE editor with AutoIT a long time ago. You could toggle a key and it would "add trace lines" between every single line of code. Yeah, I'd consider that a code smell for sure if you committed that.
Re: Logging as a code smell
#23I'm not sure this article does a good enough job of explaining why it's a code smell. Aside from the event bus code looking slightly better, I don't see any big advantages. One disadvantage is that if you have a big class with lots of different events, you now have to import all of your events rather than just importing the singular logger. Typically I only resort to logging in situations where I don't want to propag…
Awful hard to attach a debugger to a production system?
What if you don’t have physical access to a production system?
Re: Logging as a code smell
#24Re: Logging as a code smell
#25I'm not sure this article does a good enough job of explaining why it's a code smell. Aside from the event bus code looking slightly better, I don't see any big advantages. One disadvantage is that if you have a big class with lots of different events, you now have to import all of your events rather than just importing the singular logger. Typically I only resort to logging in situations where I don't want to propag…
Logs are useful because they give an idea of what was going on when a particular failure happened. More context than a call stack.
> Pretty disappointed with the actual post.
I am as well. What the author describes isn't new or novel, it's been in Windows in the form of ETW since the early 90's. And Windows wasn't the first OS to get it. Had the author taken a serious System/OS class he would have known.
You can't build high performance applications without using some scheme similar to what the author describe.
Re: Logging as a code smell
#26I love the idea of an event bus, but all I use is C and embedded. The last time I considered it I backed away from it. Wish there was effort to establish a pattern for this in C.
I believe ZeroMQ has libraries/implementation suitable for embedded systems.
Checked it out, no go.
Replies extremely heavy on POSIX api and threads. All the cool functionality is with sockets. There is an inproc:// but it doesn’t do much.
Lighter to just work it out using RTOS objects like queues and streams.
Re: Logging as a code smell
#27Re: Logging as a code smell
#28The real code smell here is importing a third-party library into all of your application classes.
Wrap it in a class of your own so the logger (or whatever) can be easily swapped out if you want to use a different logging system, events, or whatever.
Re: Logging as a code smell
#29Logging is something you do for some future purpose. If I write a string in a log message, the future purpose is usually for me to read it later.
The reasons in the post did not convince me on why my log messages should be structured. For example, why would I want to internationalize those messages?
Re: Logging as a code smell
#30The event bus in all these examples looks an awful lot like just a different name for a log, and adding an event bus has some minor downsides in that it requires more complex setup (with additional points of failure and points of difference between local and production deployment) and you would need to use special tooling to get the actual messages recorded somewhere and your hands on the contents of the messages when you need to debug. On the flipside the event bus messages may be useful for more than just human debugging.
It's a shame the author didn't actually look at logging as a code smell. For example, is a high density of logging statements in code an indication of places which are brittle and hard to figure out and therefore candidates for reworking? That would be an interesting topic I think.