Towards a Taxonomy of Software Log Smells

This paper presents a taxonomy of nine log smells derived from a survey of 51 studies to help developers write better logging code, while also mapping these issues to existing repair tools and highlighting critical gaps in current research and tooling.

The Gist

Imagine you are a detective trying to solve a crime in a massive, chaotic city. Your only clues are the diaries (logs) left behind by the city's citizens (the software). If the diaries are written in a secret code, filled with typos, missing pages, or contradictory stories, you'll never solve the crime. You'll be stuck in the dark.

This paper is about fixing those diaries.

The authors, researchers from Luxembourg and the UK, noticed that while software engineers are great at building apps, they often write terrible "diaries" (logs) about what those apps are doing. These bad logs lead to confusion, wasted time, and even security leaks.

To help, the team created a "Smell Taxonomy." Think of this as a Wanted Poster for bad logging habits. Just like a detective knows that "smoke" might mean a fire, developers need to recognize "smells" that mean something is wrong with their code.

Here is the breakdown of their findings, translated into everyday language:

1. What is a "Log Smell"?

In software, a "smell" isn't a bad odor. It's a warning sign. It's like seeing a wobbly leg on a table. The table still stands (the software still runs), but it's a sign that something is poorly designed and might collapse later.

The authors found 9 specific "Smells" that developers should avoid. They grouped them into two categories: The Code (how the diary is written) and The Diary (what the diary actually says).

The 9 "Smells" (The Bad Habits)

A. Smells in the Diary (The Log Files)

These are problems you see when you actually read the logs.

1. Format Turmoil (The Messy Handwriting): Imagine one person writes in cursive, another in block letters, and a third uses a different language. If your logs don't follow a standard format, it's impossible to search them or read them quickly.
2. Undercover Identifier (The Anonymous Note): A diary entry says, "The bank vault was opened," but it doesn't say who opened it. Without a name (or ID) attached to the log, you don't know which part of the system caused the problem.
3. Mercurial Logging Level (The False Alarm): This is like a smoke detector that screams "FIRE!" when you just toast a piece of bread. The log says "ERROR" for a minor issue, or "INFO" for a disaster. It makes it hard to know what actually matters.
4. Deceptive Variable (The Missing Ingredient): The log says, "The car broke down," but it forgets to say which car or what part broke. It's like a recipe that says "add spices" but doesn't list which ones.
5. Message Madness (The Nonsense Story): The log entries are full of typos, bad grammar, or confusing sentences. "Connect to data base" vs "Connected to database." It makes the story hard to follow.
6. Logging Lost in the Wind (The Missing Page): The diary has a gap. The software crashed, but the log entry that should explain why is simply missing. It's like a detective arriving at a crime scene and finding the most important page torn out.
7. Landfill Logs (The Garbage Dump): This is the opposite of missing pages. The software writes too much. It logs every single breath the computer takes. The important clues are buried under thousands of lines of useless noise, like trying to find a diamond in a mountain of trash.

B. Smells in the Code (How the Diary is Written)

These are problems in the actual programming code that generates the logs.

8. Sleeping Guards (The Lazy Bouncer): Imagine a bouncer at a club who is supposed to check IDs but falls asleep. In code, this means the computer is doing the hard work of writing a log entry even when nobody is looking at it. It wastes energy and slows down the system.
9. Skeleton in the Closet (The Messy Room): The code that writes the logs is itself messy, duplicated, or hard to understand. If the "writer" is confused, the "diary" will be too.

2. Why Does This Happen? (The Causes)

The paper also looked at why these smells exist. It's usually not because developers are lazy, but because of:

• No Rulebook: Everyone has their own way of writing logs.
• Experience Gap: New developers might not know what to log.
• Too Many Tools: Using different "notebooks" (libraries) that don't talk to each other.
• Neglect: Updating the app but forgetting to update the logs.

3. What Happens If We Ignore Them? (The Consequences)

If you ignore these smells, the "diary" becomes useless, leading to:

• Leaking Secrets: Accidentally writing passwords or private user data into the log file.
• Time Travel Confusion: The log says Event B happened before Event A, but in reality, it was the other way around.
• Slow Motion: The system runs so slowly because it's busy writing useless logs.
• Ghost Bugs: The act of logging something actually changes how the software behaves, creating new bugs.

4. The Toolkit (The Solutions)

The researchers checked if there are any tools to fix these smells.

• Good News: There are about 16 tools that can help fix things like "False Alarms" (wrong log levels) or "Missing Pages" (missing logs).
• Bad News: There are almost no tools to fix the "Messy Handwriting" (Format Turmoil) or the "Lazy Bouncer" (Sleeping Guards). These are areas where future researchers need to invent new tools.

The Big Takeaway

Writing good logs is like writing a good mystery novel: it needs a clear plot, consistent characters, and no missing pages.

This paper gives developers a checklist (the taxonomy) to spot the bad habits before they cause a disaster. It tells us: "Hey, your logs smell like a landfill; let's clean them up before the system crashes."

By understanding these "smells," developers can write better software, debug faster, and sleep better at night knowing their digital diaries are actually useful.

Technical Summary

Here is a detailed technical summary of the paper "Towards a Taxonomy of Software Log Smells" by Saarimäki, Shin, and Bianculli.

1. Problem Statement

Software logging is a critical component of modern development, essential for debugging, testing, and anomaly detection. However, producing high-quality logs is non-trivial due to the complexity of design decisions, coordination among developers, and the dual nature of logging (affecting both source code and the resulting log files).

While the concept of "smells" (indicators of deeper design problems) is well-established in other areas of software engineering (e.g., code smells, requirements smells), it is not yet comprehensively defined or categorized for logging. Existing literature focuses on specific issues (e.g., duplicate code or specific anti-patterns) or categorizes logging by process (what, where, when, how to log) rather than by the quality issues themselves. This lack of a unified taxonomy hinders developers' ability to identify, prevent, and repair logging issues early in the lifecycle.

2. Methodology

The authors conducted a literature survey (rather than a full Systematic Literature Review due to resource constraints) to identify logging issues and existing repair tools.

• Data Sources: Google Scholar, IEEE Xplore, Scopus, and ACM Digital Library.
• Search Strategy: 14 search queries targeting terms like "log quality," "logging code smell," and "bad logging practices."
• Selection Criteria: 51 peer-reviewed papers (published 2000–2025) were selected after filtering 380 unique results. Papers were excluded if they were duplicates or did not describe specific logging issues.
• Analysis Technique:
  1. Open Coding: One author extracted 51 logging issues from the papers.
  2. Open Card Sorting: All authors grouped these issues to identify initial categories.
  3. Closed Card Sorting: The authors iteratively refined the categories into a consensus taxonomy, distinguishing between Causes, Log Smells, and Consequences.
  4. Tool Mapping: Identified tools were mapped to the specific facets of the log smells they address (repair/detection).

3. Key Contributions

The paper makes three primary contributions:

1. Definition of Log Smell: A formal definition: "A poor design choice or an issue impacting quality that could result in a more serious problem, affecting the logging code, the log file, or both."
2. A Comprehensive Taxonomy: A hierarchical classification of 9 Log Smells, 5 Causes, and 4 Consequences, further divided into specific "facets" (ways a smell manifests).
3. Tool Mapping: A mapping of 16 existing automated tools to the specific facets of log smells they can repair, highlighting gaps in current tooling.

4. Results: The Taxonomy

The taxonomy is structured hierarchically, distinguishing between issues affecting the Logging Code (White-box) and the Log Artifact (Log File).

A. The 9 Log Smells (LS)

1. Format Turmoil (LS1): Inconsistency, incompleteness, or absence of logging formats across the project.
2. Undercover Identifier (LS2): Missing or incorrect identifiers (e.g., component ID, thread ID) in log entries, making it hard to trace the source.
3. Mercurial Logging Level (LS3): Missing, incorrect, or inconsistent log levels (e.g., logging a warning as an error, or inconsistent levels for the same event).
4. Deceptive Variable (LS4): Missing, wrong, malformed, or varying granularity of variables logged (e.g., logging an object reference instead of its value).
5. Message Madness (LS5): Issues with static log messages, including missing, wrong, imprecise, duplicated, or grammatically incorrect text.
6. Logging Lost in the Wind (LS6): Missing logging entries entirely or setting verbosity too low to capture necessary runtime data.
7. Landfill Logs (LS7): Excessive logging, including redundant, useless, or overly detailed entries that obscure important information.
8. Sleeping Guards (LS8): Missing or incorrect conditional guards around logging code, leading to performance overhead (executing code without output) or undefined variables.
9. Skeleton in the Closet (LS9): General code quality issues within the logging code itself (e.g., duplication, long methods, poor naming) that affect maintainability.

B. Causes and Consequences

• 5 Causes: Lack of guidelines, developer domain knowledge gaps, logging library incompatibility, separately developed components, and insufficient maintenance.
• 4 Consequences: Information leaks (security), temporal inconsistency (misleading event order), system performance degradation, and accidental side-effects (e.g., deadlocks).

C. Tool Analysis (RQ2)

The study identified 16 repair tools.

• Coverage: Tools cover 6 of the 9 smells but only address 14 out of 30 identified facets.
• Gaps:
  • Format Turmoil (LS1): No dedicated repair tools found (though libraries handle formatting, no tools fix inconsistency across projects).
  • Sleeping Guards (LS8) & Skeleton in the Closet (LS9): No automated repair tools found. LS8 is difficult to automate due to the need for control-flow reasoning.
  • Most Addressed: "Mercurial Logging Level" (LS3) is the most covered smell (7 tools), followed by "Message Madness" (LS5).
• Limitation: Many tools focus on detection or specific facets (e.g., only exceptions) rather than holistic repair.

5. Significance and Future Work

• Practical Impact: The taxonomy provides developers and researchers with a structured vocabulary to identify logging anti-patterns. By understanding the causes and consequences, teams can proactively improve logging quality, reducing debugging time and system performance overhead.
• Research Direction: The mapping reveals significant gaps in automated tooling, particularly for code-level smells (LS8, LS9) and format consistency (LS1). This highlights a need for new tools that can reason about control flow and cross-component consistency.
• Future Work: The authors plan to validate the taxonomy empirically by mining software repositories (MSR) to measure the real-world prevalence of these smells and to develop tools for the currently unaddressed facets.

In conclusion, this paper establishes the first comprehensive framework for understanding "log smells," moving beyond ad-hoc observations to a structured taxonomy that bridges the gap between logging code quality and log file utility.