Live data from Hacker News

Logging as a code smell

dave.autonoma.ca

11–20 of 54 posts

Re: Logging as a code smell

#11

Just like a Java programmer to tell you to use an event bus for simple diagnostics. I’m a former one, I don’t mean no offense. I go even lower though. Just print(“XXXXXXXXXXX”) print(“XXXXXXXXXXX”) print(amount)

That event bus exists whether you call it one or not — print is just a buffered serialized stream of events consumed by the kernel and rendered to strings.

Re: Logging as a code smell

#12

Just like a Java programmer to tell you to use an event bus for simple diagnostics. I’m a former one, I don’t mean no offense. I go even lower though. Just print(“XXXXXXXXXXX”) print(“XXXXXXXXXXX”) print(amount)

when my code is not working how i expect it to, i print a ton of equal signs, then the value on a knew line, then a new row of equal signs. never used loggin before.

Re: Logging as a code smell

#13
post #8
post #4

I'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?

Agreed. In a perfect world all production bugs can be reproduced on a test instance, but that's often not the case in the real world. Also, I've seen plenty of timing sensitive bugs that get covered up by the delay introduced by the attached debugger. The much feared "Heisenbug".

Re: Logging as a code smell

#14

Just like a Java programmer to tell you to use an event bus for simple diagnostics. I’m a former one, I don’t mean no offense. I go even lower though. Just print(“XXXXXXXXXXX”) print(“XXXXXXXXXXX”) print(amount)

when my code is not working how i expect it to, i print a ton of equal signs, then the value on a knew line, then a new row of equal signs. never used loggin before.

You my friend need to experience an interactive debugger.

Re: Logging as a code smell

#15

I 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.

Re: Logging as a code smell

#16
post #11

Just like a Java programmer to tell you to use an event bus for simple diagnostics. I’m a former one, I don’t mean no offense. I go even lower though. Just print(“XXXXXXXXXXX”) print(“XXXXXXXXXXX”) print(amount)

That event bus exists whether you call it one or not — print is just a buffered serialized stream of events consumed by the kernel and rendered to strings.

> buffered serialized stream of events

So is a sewer though, and I wouldn’t call that an event bus either.

Re: Logging as a code smell

#17
Logging is one of many ways to debug and capture behavior in large systems. Logging is not inherently bad and isn’t an event bus just another layer or two of indirection of a logger? This post just demonstrated a logger abstraction that is still capturing and logging activities. Sort of anyway. Code smell is when your logs aren’t helpful

Re: Logging as a code smell

#18

> Logging is an example of code duplication. Is it? What am I missing here?

I think the idea is you have:

(1) Some code that does a thing

(2) Another line of code that logs that the thing happened

And, like in-lined documentation, the code can diverge from the text that says what it does.

Re: Logging as a code smell

#19

> Logging is an example of code duplication. Is it? What am I missing here?

I think the idea is you have: (1) Some code that does a thing (2) Another line of code that logs that the thing happened And, like in-lined documentation, the code can diverge from the text that says what it does.

Prescriptive example from the article:

userRoles.addMember( p ); RoleAssignedEvent.publish( p, roleName );

Seems to have the exact same risk of divergence.

Depending on the language you can (and I have) used decorators/higher order functions to log the invocation of a function with its name and arguments. Zero risk of divergence there, but it was still logging not some kind of event system. The problem of divergence seems to me to be orthogonal.

Re: Logging as a code smell

#20
Debugging complex systems in production is much easier, if you can rely on certain things. Thus, simple logging to files using known configuration eliminates one variable to debug. With an event bus, there’s always the question of “did the event not happen or did some upfckery prevent the message from getting where I can see it?”.

While I do agree with the need to simplify code, moving to an event bus transfers the complexity to where we don’t necessarily want it - to system level. Now there’s one more moving thing to be deployed, monitored, scaled, networked. And, by the way, that moving thing is mission critical, as without it you are flying blind, including in terms of infosec. Is it worth it? Maybe in some scenarios. But definitely not to the level of a code smell, that should be something to be avoided universally.

Post reply on HN