Logs in code

Image from thumbs.dreamstime.com

When writing code, many developers especially junior level, don't understand the importance of having logs in their code. I was also a victim of this. This article will delve a bit into the importance of logs in your development cycle and how you can implement them.

The Importance

So recently I've been developing a personal finance tool. When trying to do add a transaction performed it brings errors but they don't state where the issue is.

This is what is be displayed on the website:

It shows there's an issue in the way the time is being parsed. The bigger issue is that the error message is being displayed to the user which is a mistake on my part. Still, this would be better shown in the logs. As for the logs, this is what is displayed:

The image just shows that there was a bad request and nothing else, no context. So I didn't even know where to begin with in terms of fixing my code.

Back to the matter at hand, the importance of adding logs to your code. So what exactly is logging?

Logging can be defined as writing text describing what’s been happening in your program to a file or other storage system. Logging is essential for debugging and troubleshooting. When there's a bug, you need to find out which specific part of the program is broken, because it’s often not the part that’s visibly acting weird. This is often the first step in addressing a new bug after reproducing it, or even part of figuring out how to reproduce it.

In fact, logs can be helpful at every stage of the debugging process. You have to confirm your assumptions on what parts are known to work. After all, the whole program is supposed to work, and often times, the thing that’s broken is something that you would’ve assumed definitely worked.

How to implement it

So I got to work and added a few lines of code to see the actual reason why the transactions were not being created.:

The code initially just returned the err, but the slog.Error code allows for a more detailed error to be shown in the logs. Like so:

The line in red is:

{
"time":"2026-05-25T10:47:02.872094934Z",
"level":"ERROR",
"msg":"CreateTransactions failed",
"user_id":"a7e2fa58-712c-4fed-9783-35272ea7e2a1",
"account_id":"1ad6e60e-b104-4dc4-91d7-b22de26ee972",
"amount":2300,
"type":"expense",
"error":"Type can only be income or exepense"
}

As you can see in the logs, the error is more detailed and I can see that the error is a typo in my own code base, since it is an error 500(internal). So Upon closer inspection of my code I realized, that I wrote something entirely different.

Instead of expense I wrote:

That's an error on my part(coding while tired). but I wouldn't have known to go back to my code and check, if I didn't have that error message.

So for you the reader you:

1. Choose a Standard Library or Framework

Avoid using print() for permanent logging, as it lacks control over levels and destinations. Use established tools for your language:

• Python: The built-in logging module.
• Java: Log4j2 or Logback via SLF4J.
• Node.js: Winston or Bunyan.
• Go: Log
• Rust: The log crate facade

2. Define Severity Levels

Categorizing messages will allow you to filter logs in different environments (e.g., show only errors in production but everything in development).

• DEBUG: Detailed information for diagnosing problems during development.
• INFO: Confirmation that things are working as expected (e.g., service started).
• WARNING: Indication that something unexpected happened, but the software is still working.
• ERROR: Serious problems where a specific function failed to execute.
• CRITICAL: Fatal errors indicating the program itself may be unable to continue.

3. Configure Loggers, Handlers, and Formatters

A strong setup has three main components:

• Loggers: The entry point where your code sends messages (e.g., logger.info("Starting process")).
• Handlers (Appenders): Determine where the logs go—such as the console, a local file, or a remote server.
• Formatters: Define the layout of the log message. A standard format includes: [Timestamp] [Level] [Source/Module] [Message].

4. Best Practices for Better Logs

• Structured Logging: Use JSON or key-value pairs instead of plain text to make logs easily searchable by machines.
• Include Context: Log useful identifiers like user_id or transaction_id, but never log sensitive data like passwords or credit card numbers.
• Log Exceptions: In try-except blocks, use logger.exception() to automatically capture the full stack trace.
• Use UTC Timestamps: Standardizing on UTC avoids confusion when working across different time zones.
• Centralize Configuration: Configure logging once at the project's entry point (e.g., your main.py or App.java) rather than in every individual file.

Conclusion

Working with logs has saved me a lot of time in debugging and looking for errors where none can be seen. In development its easier to spot issues but in production it can be a nightmare. I encourage every developer especially the beginners to start using logs as early as your current project. It'll save you a lot of time and make your development journey a little bit easier.