Coder Legion - Recent posts tagged codesmell

Code Smell 322 - Request Data in Long-Lived Variables (PHP Vulnerability)

Wed, 21 Oct 2026 23:57:47 +0000

Your request is gone. Your pointer is not.

TL;DR: Don't keep request-owned pointers in long-lived variables, or the next request reads freed memory.

Problems 😔

Use after free on stale request memory
Remote code execution
Hidden side effects
Stale state crosses into a later request
Stale values, like a bad cache
Tests miss cross-request failures

Solutions 😃

Scope state per request
Centralize state ownership
Initialize before early consumers
Clear references before freeing
Cover every exit path
Block late writes
Test consecutive worker requests

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-024-replace-global-variables-with-dependency-injection

Context 💬

A server process can live for hours and handle many requests in a row, while a request may last milliseconds.

When you store a request's pointer in a process-wide variable, you tie two lifetimes together without saying so.

The request ends and the runtime frees its memory, but the variable keeps the address.

The next request starts, and some code runs before initialization and reads that variable.

It trusts the address, but something else may already be using that memory.

A fatal error can interrupt an operation before it resets its state.

Timeouts, uncaught errors, and memory exhaustion can all trigger this path.

Late writes can also repopulate state after shutdown has already cleared it.

The defect depends on both sides: one operation leaves stale state behind, and another operation reads or acts on it.

An attacker needs two requests handled by the same worker: one that leaves a stale value and one that reads it.

Under the right memory layout, that sequence turns a use after free into remote code execution.

This smell lives in native code, like a language runtime or an extension, where you manage memory by hand.

Sample Code 💻

Wrong 🚫

// CONCEPTUAL MODEL: NOT php-src code and NOT an exploit.
// Don't use this skeleton to try to reproduce the real
// attack vector. It exists only to show the lifetime defect.
// All names are invented, except the quoted TODO at the end.
//
// A worker serves many requests in a row.
// Its globals live as long as the worker does.
static error_state *last_error;  // points into request memory

void request_shutdown(void) {
    if (fatal_error_happened) {
        free_request_memory();
        return;  // skips the reset below
    }
    free_request_memory();
    last_error = NULL;
}

// A second way to get stale state: a late warning during
// shutdown refills the global AFTER it was cleared.
void late_diagnostic(const char *message) {
    last_error = new_error_state(message);
}

// The next request calls this before it initializes
// anything, and trusts the stale value.
void report_error(void) {
    use(last_error);
}

// Real, from ext/session/session.c: a TODO the patch
// removed from php_rinit_session_globals():
// "These could be moved to MINIT and removed.
//  These should be initialized by
//  php_rshutdown_session_globals() always when
//  execution is finished."

Right 👉

The first example shows selected excerpts from the actual PHP fix.

// EXCERPTS FROM THE PHP FIX: commit 31c0ea7d7ff (reordered).
// This is NOT the complete fix. The commit also replaces
// out-of-memory bailouts with a delayed soft failure plus a
// hard exit at a higher threshold, and it touches many
// runtime components. Only resets and early init shown here.
// They illustrate Solutions 3, 4 and 5.
//
// Ref: Zend/zend_execute_API.c,
//      zend_shutdown_executor_values()
// The backtrace field below exists only in PHP 8.5.
/* may be used by zend_error_zstr_at before init_executor */
ZVAL_UNDEF(&EG(last_fatal_error_backtrace));
EG(record_errors) = false;
EG(num_errors) = 0;
EG(errors) = NULL;
EG(error_handling) = EH_NORMAL;
EG(exception) = NULL;

// Ref: main/main.c, php_request_shutdown()
/* May be accessed before php_request_startup() */
// (inside the loop that destroys each http_global)
ZVAL_UNDEF(&PG(http_globals)[i]);
// (end of the function)
PG(modules_activated) = 0;

// Ref: ext/session/session.c,
//      php_session_rfc1867_callback(),
//      case MULTIPART_EVENT_START
/* This runs before RINIT, so we need to clear these early */
php_rinit_session_globals();

The second example is a design sketch, not PHP code.

It illustrates one possible approach to managing state ownership and cleanup.

// DESIGN LESSON: NOT the PHP patch, only a sketch.
// It isn't production-ready: it needs real ownership
// and lifetime rules for every resource it touches.
// It shows Solutions 1 to 6.
//
// The request owns its state, so nothing outlives it.
void handle_request(worker *w) {
    request_ctx ctx;
    request_ctx_init(&ctx);
    // run_request() must come back here on fatal errors
    // too, so cleanup runs on every exit path.
    run_request(w, &ctx);
    request_ctx_cleanup(&ctx);
}

// Each state owner gets an explicit cleanup operation.
void errors_owner_cleanup(errors_owner *owner) {
    // 1. Refuse late updates. This alone isn't enough:
    //    every other path that can publish a reference
    //    must also go through the owner.
    owner->accepting_updates = false;
    // 2. Clear every reference into request memory.
    clear_references_into_request_memory(owner);
    // 3. Release what the owner owns.
    release_owned_resources(owner);
}

// Call it before request memory is released, on every
// exit path. Then initialize the owner before any early
// consumer can read it during the next request.

Detection 🔍

[X] Semi-Automatic

You search for variables that hold a pointer to request memory but live in process scope.

You compare every startup initialization with its shutdown reset, and a variable missing from one of them is suspect.

Symmetry alone isn't enough, because a late write can bring the stale value back after the reset.

For runtime or native-extension code, you need an instrumented build with AddressSanitizer or Valgrind, sometimes with the runtime's own allocator disabled.

You send consecutive requests through the same worker, make the first one fail on purpose, and inject allocation failures so the error paths run.

Exceptions 🛑

Data that truly belongs to the process, like configuration or compiled caches, can live as long as the process.

The smell appears only when that data refers to request-owned memory or state.

The smell matters most in runtimes with persistent workers, where one process serves many requests in a row.

You shouldn't rely on a process dying to clean up after you.

Tags 🏷️

Security

Level 🔋

[x] Intermediate

Why the Bijection Is Important 🗺️

A request is a bounded interaction in the MAPPER.

When it ends, everything that belongs to it ends too.

When your code lets a piece of that interaction survive in a global, you break the bijection.

The model now holds something that no longer exists in the MAPPER.

The next interaction inherits a stale reference and trusts it, because nothing marked it as dead.

AI Generation 🤖

AI-generated code can introduce this smell when it uses global state to avoid passing dependencies explicitly.

You ask for a shared status value, a cache, or a shortcut that avoids passing a parameter through five functions.

Using a global may seem like the smallest change that solves the problem.

The risk grows when the code runs in long-lived workers and stores references to shorter-lived memory.

AI Detection 🧲

AI can detect it if you ask for a lifetime analysis.

Try: "List every global that stores a pointer to request-scoped memory and show where each one gets reset, including error paths."

A generic review prompt may miss lifetime problems that appear only on error paths or across consecutive requests.

Try Them! 🛠

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Find every global that holds a pointer to request-scoped memory, give each long-lived variable an explicit reset, and run it on every exit path before the request's memory is freed

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion 🏁

A global can outlive the memory its pointer references.

That mismatch is what makes it a smell.

When you see a long-lived variable pointing at short-lived memory, you should move it into request scope or reset it on every exit path.

You should also initialize it before any early consumer can read it, and block late writes from bringing the old value back.

You can't count on the error path never running, so you should test it.

Relations 👩❤️💋👨

https://maximilianocontieri.com/code-smell-32-singletons

https://maximilianocontieri.com/code-smell-60-global-classes

https://maximilianocontieri.com/code-smell-49-caches

https://maximilianocontieri.com/code-smell-209-side-effects

More Information 📕

The PHP team recommends upgrading to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, because configuration changes don't make a vulnerable installation safe.

PHP 8.1 and older no longer get updates, but the PHP team published source-only backports for 7.4, 8.0 and 8.1, and some vendors ship their own fixes.

One commit fixes both CVEs: CVE-2026-109619 (stale global state) matches this smell, while CVE-2026-109618 (out-of-memory bailout) is a related early-exit problem that fits only partly.

Apache mod_php has a demonstrated exploitation path and PHP-FPM has documented exposure under specific conditions, so you shouldn't assume another SAPI removes the risk.

The fix: php-src commit 31c0ea7d7ff, "Avoid state corruption via bailout" (one combined patch for both CVEs below; it also replaces out-of-memory bailouts with a delayed soft failure, plus a hard exit at a higher threshold)

https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

PHP2Shell: all you need to know (JFrog) (this write-up pairs the CVE numbers with the opposite mechanisms; the GitHub advisories above are the reference)

https://cwe.mitre.org/data/definitions/416.html

https://cwe.mitre.org/data/definitions/824.html

Quote

Simplicity is prerequisite for reliability.

Edsger W. Dijkstra

Disclaimer 📘

Code Smells are my opinion.

Credits 🙏

Photo by Bernd Dittrich on Unsplash

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

Code Smell 321 - Getter Piggybacking

Fri, 21 Aug 2026 12:43:11 +0000

One broken window invites another

TL;DR: Don't reuse an existing getter to bolt on new business logic from outside the object.

Problems 😔

Duplicated business rules
Broken encapsulation
Scattered comparison logic
Hidden domain knowledge
Fragile refactoring
Law of Demeter violation

Solutions 😃

Add real behavior methods
Keep comparisons inside object
Pass collaborators, not primitives
Reserve getters for rendering
Follow tell, don't ask

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-027-remove-getters

https://maximilianocontieri.com/refactoring-013-remove-repeated-code

Context 💬

An object exposes a getter for one legitimate reason: some other part of the system needs to read that value, usually to display it.

Getters are a code smell, but this one gets a pass, for now.

Later on, you discover that you need new business logic that depends on the same value.

You already have the getter, so you write a function outside the object that calls it and does the comparison itself, breaking the encapsulation principle.

Someone else needs slightly different logic based on the same value.

They also call the getter and write their own version of the comparison.

Now two places decide what that value means, and neither of them is the object that owns it. Typical.

You didn't add a second getter this time.

You reused the first one, because it was already there.

That's the trap.

The getter existed for one reason, and you let it justify skipping the real fix: a method on the object that answers the question itself, instead of handing out the raw value for every caller to interpret on their own.

Don't break more windows

Sample Code 💻

Wrong 🚫

// Food needs to show its use-by date on the shelf
// label, so useByDate() exists for that one reason.
//
// Later, removeExpiredFood() needs to pull expired
// products, so it reuses useByDate() and compares the
// result to today itself, outside Food.
//
// flagNearExpiryFood() needs almost the same check, so
// it also calls useByDate() and writes its own slightly
// different comparison.
//
// Now two functions decide what "expired" means, and
// neither of them is Food.
class Food {
  constructor(name, useByDate) {
    this.name = name;
    this.useByDateValue = useByDate;
  }

  useByDate() {
    return this.useByDateValue;
  }
}

function removeExpiredFood(shelf, today) {
  return shelf.filter(
    food => food.useByDate() >= today
  );
}

function flagNearExpiryFood(
  shelf, today, warningDays
) {
  return shelf.filter(food => {
    const daysLeft = daysBetween(
      food.useByDate(), today
    );
    return daysLeft >= 0 &&
      daysLeft <= warningDays;
  });
}

Right 👉

// Food still exposes useByDate() for the shelf label.
//
// Being expired is now a question Food answers itself,
// through isExpiredOn(), instead of every external
// function reimplementing the comparison from the
// getter on its own.
class Food {
  constructor(name, useByDate) {
    this.name = name;
    this.useByDateValue = useByDate;
  }

  useByDate() {
    return this.useByDateValue;
  }

  isExpiredOn(today) {
    return this.useByDateValue < today;
  }

  daysUntilExpiryFrom(today) {
    return daysBetween(this.useByDateValue, today);
  }
}

function removeExpiredFood(shelf, today) {
  return shelf.filter(food => !food.isExpiredOn(today));
}

function flagNearExpiryFood(shelf, today, warningDays) {
  return shelf.filter(food => {
    const daysLeft = food.daysUntilExpiryFrom(today);
    return daysLeft >= 0 && daysLeft <= warningDays;
  });
}

Detection 🔍

[X] Manual

This is a design smell, and no linter is coming to save you.

Search for a getter that appears inside if, comparison, or filter expressions in more than one place outside its own class.

If two call sites read the same getter and each writes its own comparison against it, the object is missing a method, and the getter is carrying logic it was never meant to carry.

Exceptions 🛑

The smell appears when you reuse that same getter as a shortcut for business logic instead of adding the method the logic actually belongs to.

Don't point to DTOs as a counterexample. A DTO doesn't excuse this. It just breaks encapsulation on purpose and gives the practice a name.

Tags 🏷️

Encapsulation

Level 🔋

[x] Intermediate

Why the Bijection Is Important 🗺️

The rule behind that value is a concept that belongs to the object in the MAPPER, not to whichever function happens to call the getter first.

When you keep that rule inside the object, every caller shares the same bijection between the object and the real-world thing it represents.

When you let each caller reimplement the rule from a getter, you create as many private definitions of that concept as you have call sites, and they drift apart the moment one of them changes.

AI Generation 🤖

AI generators create this smell often.

You ask for a function that needs a value the object already exposes through a getter, and it writes a standalone function around that getter, because that's the smallest diff that satisfies the request.

It won't add a method to the object unless you ask for that explicitly.

AI Detection 🧲

AI can detect it, but only if you point it at the pattern.

Try: "Find getters called from more than one place where the caller performs its own comparison or business rule on the result."

Without that prompt, the code passes tests and looks idiomatic, so most assistants won't flag it on their own.

Try Them! 🛠

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Move the comparison logic from external functions into a real method on the object so callers stop reimplementing it from the getter

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion 🏁

A getter you added for one legitimate reason doesn't grant permission to skip every method that comes after it.

When you find yourself reaching for an existing getter to write new business logic outside the object, stop and add the method instead.

The object already knows the information.

Let it hold the rule too.

Stop treating it like a vending machine that only hands out data to whoever asks nicely.

Relations 👩❤️💋👨

https://maximilianocontieri.com/code-smell-68-getters

https://maximilianocontieri.com/code-smell-89-math-feature-envy

https://maximilianocontieri.com/code-smell-63-feature-envy

https://coderlegion.com/7246/code-smell-01-anemic-models

https://maximilianocontieri.com/code-smell-246-expiration-date

https://maximilianocontieri.com/code-smell-64-inappropriate-intimacy

https://maximilianocontieri.com/code-smell-173-broken-windows

More Information 📕

https://maximilianocontieri.com/nude-models-part-ii-getters

https://martinfowler.com/bliki/TellDontAsk.html

Encapsulation

Quote

OOP to me means only messaging, local retention and protection and hiding of state-process.

Alan Kay

Disclaimer 📘

Code Smells are my opinion.

Credits 🙏

Photo by Nathália Rosa on Unsplash

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

Real-Life Refactoring Example: ~3x Less Code to Read

Tue, 11 Aug 2026 12:45:48 +0000

There is a popular idea that refactoring is making code shorter. It is not entirely wrong. Repetition, pointless conditional branches, and dead variables do make code longer for no reason. But the usual topmost problems are when the intentions of a class's main public method, the business or operational ones, are unclear to a reader.

- [The Main Method Refactor](#the-main-method-refactor) - [A Private Helper Is Not Automatically a Public API](#a-private-helper-is-not-automatically-a-public-api) - [One String, Two Names](#one-string-two-names) - [Logging Had Become Its Own Mini-Application](#logging-had-become-its-own-mini-application) - [Deeply Buried Intention](#deeply-buried-intention) - [Actual Refactorings Used](#actual-refactorings-used) - [Make The Public Storage Flow Readable](#make-the-public-storage-flow-readable) - [Clarify Storage Vocabulary and Logging](#clarify-storage-vocabulary-and-logging) - [Result](#result)

Contents

I had such a case in an S3 document-upload adapter.

The adapter was not doing anything unusual. It had to stream a document to S3-compatible storage, count actual bytes, calculate a checksum, reject empty or too-large content, normalize S3 errors, clean up a stored object where needed, and write technical logs. This is a substantial piece of work. The problem was that the public store() method contained most of it directly.

At a glance it looked like a method that stores a document. In practice, reading it meant walking through AWS SDK setup, try/catch blocks, S3 error-object construction, cleanup, and a large logging payload before reaching the returned value.

The code was not unreadable because it had many lines. It was unreadable because the important lines had no space to stand out.

The Main Method Refactor

The main method did not show the adapter's use case. Before the refactoring, upload execution was part of store() itself:

try {
 response = await new Upload({
  client: this.#s3_client,
  params: {
   Bucket: this.#bucket_name,
   Key: documentStorageKey,
   Body: countedStream,
   ContentType: file.mime_type
  },
  leavePartsOnError: false
 }).done();
} catch (error: unknown) {
 // Detect validation errors.
 // Build an S3 error object.
 // Build an application exception.
 // Log it.
 // Throw it.
}

How do I decide what to refactor? ne rule of thumb is to watch the nesting depth. In my book, a class should not contain more than three levels of nesting. The first is the class declaration, the second is the method level, and the third is at most one level of nesting within a method - inline object literals and deeply nested objects are not allowed.

The second rule - the main public methods must reveal their intention clearly by their names and their internal code must reveal the story of how the method does what it does in the domain or integration terms.

So the first refactoring was to extract that try/catch into a story-telling method:

const response = await this.uploadToStorage(documentUUID, documentStorageKey, file, countedStream, startedAt);

It was "Extract Method" refactoring, described by Martin Fowler in his Refactoring book. The main method started to read as a story because the implementation was hidden and the method name revealed intention. It packed 40+ lines into one intention-revealing call — roughly 40x less implementation detail to scan in the main flow.

I used the same approach to extract two conditionals converting a raw S3 error into an application error, and to delete an empty object and throw another error. The first turned ~20 lines into one call, and the second reduced another ~30 lines to one call. Together, roughly 90 lines of implementation detail became three intention-revealing calls — about 30x less code to scan at this level. And look at the method names — they continue the story

this.throwIfS3Error(storedObjectKey, response, httpStatusCode, startedAt);
await this.throwIfUploadedFileIsEmpty(storedObjectKey, file, countedStream, startedAt);

Moreover, now a reader can answer the first useful question quickly: what happens when a document is stored? It is uploaded. The response is checked. Empty content and errors are dealt with.

The helper methods still contain difficult code. That is fine. Difficult code should exist where it belongs. It should not hide the business flow of the public method.

[!INFO]
The main store() method shrank from 121 lines to 39 — a 68% or 3x reduction in code to read.

A Private Helper Is Not Automatically a Public API

The next request looked small. The upload service needed to delete the object it had just stored when a duplicate document was found, or when persistence failed later in the transaction.

There was already a private cleanup method.

private async cleanupStoredObject(documentUUID: string, documentStorageKey: string, startedAt: number): Promise<void> {}

A tempting change was to make it public. That would have been wrong.

The private method accepted a document UUID, a storage key, and a timestamp. The timestamp existed only because the method wrote a cleanup-failure log. It also swallowed a deletion error. That was correct for the empty-upload path: the caller must receive the original “empty upload” error even when cleanup itself fails.

It is not a public removal contract. The public operation became this instead:

public async remove(storedObjectKey: string): Promise<void>

It now owns the S3 request. It owns the timing of the S3 operation. It normalizes the provider error. It writes the technical storage event. It throws the normalized error to its caller and it is universally used by the adapter and its caller.

public async remove(storedObjectKey: string): Promise<void> {
    const removalStartedAt = Date.now();

    try {
        await this.#s3_client.send(new DeleteObjectCommand({
            Bucket: this.#bucket_name,
            Key: storedObjectKey
        }));
    } catch (error: unknown) {
        const normalizedFailure = this.normalizeStorageFailure(error);

        this.logStorageEvent({
            logLevel: ELogLevel.ERROR,
            eventName: EDocumentStorageLogEventName.DOCUMENT_STORAGE_CLEANUP_FAILED,
            outcome: ELogOutcome.FAILURE,
            operationName: DOCUMENT_STORAGE_LOG_CONSTANTS.operation.remove,
            storedObjectKey,
            startedAt: removalStartedAt,
            error: normalizedFailure
        });

        throw normalizedFailure;
    }
}

The caller decides what to do with that error.

The remove() itself catches it for an empty upload because empty content remains the reported result. The adapter's caller - the upload service - will catch it for a duplicate upload because a duplicate remains the domain concern, not the adapter's one. These are different decisions made by different owners.

One String, Two Names

Naming was not cosmetic in this refactoring. The application has a document UUID. The S3 adapter uses an object key. They were used in the multiple adapter logging methods extracted from the main store() method.

private logFailure(documentUUID: string, documentStorageKey: string, error: MinimalRAGException, startedAt: number): void {}

The document UUID is part of the key:

const storedObjectKey = `raw/${documentUUID}`;

The domain value object returns it as document_storage_key, because it is document metadata from the domain side. Inside the S3 adapter, it is storedObjectKey, because it is passed to the AWS SDK as Key.

The difference matters most when deleting an object.

At one point, removal was proposed as remove(documentUUID), with the adapter reconstructing raw/<UUID>. It looked tidy. But the exact key is already known after store() returns. Rebuilding it makes removal depend on a key layout which may later change. Passing the known stored object key is simpler and more honest.

The final refactoring replaces multiple log methods with one (Parameterize Method), parameterized with an object instead of a long list of positional parameters (Introduce Parameter Object). The method signature becomes 2x shorter, with intention-revealing names that are clear at first sight.

private logStorageEvent(options: TLogStorageEventOptions): void {}

Logging Had Become Its Own Mini-Application

This refactoring describes the other dimension of the refactoring result shown above.

The adapter had a method for successful storage. Another for successful removal. Another for S3 failure. Another for validation failure. Another for cleanup failure.

They all built nearly the same event:

{
    event_name,
    event_type: ELogEventType.INTEGRATION,
    outcome,
    resource: { storage_key: storedObjectKey },
    operation,
    error_code?,
    error?
}

Different logging events are useful. Five separate ways to construct 70%-identical logging event are not.

private logSuccess(documentUUID: string, documentStorageKey: string, startedAt: number, actualByteSize: bigint, httpStatusCode: number | undefined): void {}

This is where a long argument list becomes a real problem. Six positional arguments might compile. Nobody wants to remember their order during a production incident.

The final code uses the single logging method and one parameter object:

type TLogStorageEventOptions = TLogStorageSuccessOptions & {
 logLevel: ELogLevel;
 outcome: ELogOutcome;
 error?: MinimalRAGException;
};

// ...

this.logStorageEvent({
 logLevel: ELogLevel.WARN,
 eventName: EDocumentStorageLogEventName.DOCUMENT_STORAGE_VALIDATION_FAILED,
 outcome: ELogOutcome.FAILURE,
 operationName: DOCUMENT_STORAGE_LOG_CONSTANTS.operation.store,
 storedObjectKey,
 startedAt,
 actualByteSize: countedStream.actual_byte_size,
 error: rejection
});

The refactoring reduced roughly 90 lines the reader previously had to scan to about 30.

Deeply Buried Intention

The builder of the logged object initially contained code like this, which is completely opaque:

{
    operation: new LogOperationVO({
        // other fields
        ...(cause?.request_id ? { provider_request_id: cause.request_id } : {})
    }),
}

That conditional object spread was very far from readable.

I extracted values into interim constants with intention-revealing names and used them in the logged object construction:

// Extract all ternaries to the clearly named constants
const actualByteSize = options.actualByteSize?.toString() ?? null;
const httpStatusCode = options.httpStatusCode ?? cause?.http_status_code ?? null;
const providerRequestId = cause?.request_id ?? null;
const storageError = cause
 ? new LogErrorVO({
    name: cause.error_name,
    message: cause.error_message,
    dependency: DOCUMENT_STORAGE_LOG_CONSTANTS.dependency
   })
 : null;

// Call the logger
this.#logger.log(options.logLevel, {
 operation: new LogOperationVO({
  // Other fields
  actual_byte_size: actualByteSize,
  http_status_code: httpStatusCode,
  provider_request_id: providerRequestId
 }),
 error: storageError
});

This makes the final log event construction boring. That is good. Logging is repeated often enough throughout an application that it should better be DRY.

Actual Refactorings Used

For readers who care about Fowler’s refactoring names, here is the short record.

Make The Public Storage Flow Readable

Change	Fowler refactoring
Move inline upload and its error handling into `uploadToStorage(...)`.	Extract Method
Move raw S3 error conversion into `normalizeStorageFailure(...)`.	Extract Method
Move empty-object deletion into `cleanupStoredObject(...)`.	Extract Method
Move response and empty-stream checks into named methods.	Extract Method
Move successful-storage logging out of `store()`.	Extract Method

Clarify Storage Vocabulary and Logging

Change	Fowler refactoring
`documentUuid` to `documentUUID`.	Rename Variable / Rename Parameter
Repeated S3 literals into `DOCUMENT_STORAGE_LOG_CONSTANTS`.	Replace Magic Literal with Symbolic Constant
`documentStorageKey` to `storedObjectKey` inside the adapter.	Rename Variable
Long logging parameters into `TLogStorageEventOptions`.	Introduce Parameter Object
Conditional payload expressions into named locals.	Extract Variable
Separate log methods into `logStorageEvent(...)`.	Extract Method

The public remove(storedObjectKey) method is not a Fowler refactoring. It is a new adapter capability. The validation event rename is not one either. It changes the meaning of the logged outcome. Calling every improvement a refactoring only makes the word less useful.

Result

The adapter did not become magically small. It should not. It now does more than it did before: it exposes removal, logs useful operational information, returns a named S3 response type, and gives the upload service a clean cleanup operation.

And the public path is now readable as a path:

const response = await this.uploadToStorage(...);
this.throwIfS3Error(...);
await this.throwIfUploadedFileIsEmpty(...);
this.logStorageEvent(...);

That is the result I want from refactoring - saving the reader's cognitive capacity for the really important work: deciding what, when and how the application should do in business and integration terms.

NB: The initial code implementation I had to refactor was written by AI.

Code Smell 138 - Packages Dependency

Thu, 06 Aug 2026 00:19:32 +0000

There's an industry trend to avoid writing code as much as possible, because who has time to write eight lines when a stranger already published a package for it. Turns out that convenience isn't free

TL;DR: Write your code unless you need an existing complex solution

Problems 😔

Coupling
Security problems
Architectural complexity
Packages Corruption

Solutions 😃

Implement trivial solutions
Rely on mature dependencies

Context 💬

Recently, there's a trend to rely on dependencies so hard to trace you'd need a private investigator, not a debugger.

This introduces coupling into your designs and architectural solutions, which is a polite way of saying you handed strangers the keys to your codebase.

In August 2026, an attacker compromised the maintainer account behind Keyv and injected credential-stealing code into it, right around the time thousands of developers were happily typing npm install without a second thought.

The malware spread through worm-like propagation to at least 444 packages across more than 2 billion monthly installs before anyone noticed, because auditing your transitive dependency tree is apparently nobody's job until it explodes.

You had no way to see this coming just by reading your own code, which was the whole point of importing it instead of writing it.

Sample Code 💻

Wrong 🚫

$ npm install --save is-odd

// https://www.npmjs.com/package/is-odd
// This package has about 500k weekly downloads

module.exports = function isOdd(value) {
  const n = Math.abs(value); 
  return (n % 2) === 1;
};

Right 👉

function isOdd(value) {
  const n = Math.abs(value); 
  return (n % 2) === 1;
};

// Just solve it inline

Detection 🔍

[X] Automatic

You can check your external dependencies and stick to the minimum, assuming you can list them all without opening a spreadsheet.

You can also depend on a certain concrete version to avoid hijacking, though pinning a version just means you trust yesterday's stranger instead of today's.

Tags 🏷️

Security

Level 🔋

[X] Intermediate

Why the Bijection Is Important 🗺️

Your design should map to the MAPPER with a clean bijection.

When you pull in an external package for a trivial rule, you stop owning that piece of the model.

The package maintainer's decisions become part of your bijection, whether you reviewed them or not.

You lose traceability between your domain concept and the code that implements it.

A concrete version pin restores part of that bijection, but you still depend on someone else's model matching yours.

AI Generation 🤖

AI code generators often suggest importing a popular package for problems you could solve in a few lines.

They pattern-match toward the most common solution in their training data, which is usually "there's a package for that."

Ask an assistant to check if a number is odd, and it may reach for a library instead of a single modulo operation, because apparently even parity checks need a supply chain now.

AI Detection 🧲

AI generators rarely flag unnecessary dependencies on their own.

They don't weigh the coupling cost of a package against the cost of writing the trivial logic yourself.

You need to explicitly instruct the assistant to prefer inline solutions for trivial problems and reserve dependencies for real complexity.

Try Them! 🛠

Suggested Prompt: Replace the trivial external package dependency with a small inline implementation that removes the unnecessary coupling

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Remember: AI Assistants make lots of mistakes

Conclusion 🏁

Lazy programmers push reuse to absurd limits.

You need a good balance between code duplication and crazy reuse.

As always, there are rules of thumb, no rigid rules, and plenty of developers who'll learn the difference the hard way anyway.

Relations 👩❤️💋👨

https://maximilianocontieri.com/code-smell-94-too-many-imports

https://maximilianocontieri.com/code-smell-300-package-hallucination

More Information 📕

Disclaimer 📘

Code Smells are my opinion.

Credits 🙏

Photo by olieman.eth on Unsplash

Thanks to Ramiro Rela for this smell

Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges, and it causes end-user and administrator frustration.

Ray Ozzie

https://coderlegion.com/13786/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

Code Smell 208 - Null Island

Fri, 31 Jul 2026 15:58:10 +0000

You can avoid null if you try

TL;DR: Don't use null for real places

Problems 😔

Tight Coupling
Unexpected Results

Solutions 😃

Model unknown locations polymorphically

Context 💬

Null Island is a fictional place that sits at 0°N 0°E, at the intersection of the Prime Meridian and the Equator in the Atlantic Ocean.

Many GPS systems place data with missing or invalid coordinates at this exact point. That's where the name "Null Island" comes from.

There's no landmass at this location. It's open ocean.

This point has become a popular reference for geographic information systems (GIS) and mapping software, because it helps filter out errors in location data.

Data visualization specialists started using the term around 2008, after noticing that failed geocoding requests and invalid coordinate entries often defaulted to (0, 0).

Natural Earth, a public domain mapping dataset, deliberately includes a fictional one-square-meter island at that exact point to help catch geocoding errors. The trick works: researchers have found more than 300,000 Flickr photos and countless social media posts geotagged to Null Island, and during the COVID-19 pandemic, Johns Hopkins' tracking dashboard plotted confirmed cases there whenever the real location was missing.

Sample Code 💻

Wrong 🚫

class Person(val name: String, 
             val latitude: Double,
             val longitude: Double)

fun main() {
    val people = listOf(
        Person("Alice", 40.7128, -74.0060), 
        // New York City
        Person("Bob", 51.5074, -0.1278), 
        // London
        Person("Charlie", 48.8566, 2.3522), 
        // Paris
        Person("Tony Hoare", 0.0, 0.0) 
        // Null Island
    )
    
    for (person in people) {
        if (person.latitude == 0.0 && person.longitude == 0.0) {
            println("${person.name} lives on Null Island!")
        } else {
            println("${person.name} lives at " +
                    "(${person.latitude}, ${person.longitude}).")
        }
    }
}

Right 👉

abstract class Location {
    abstract fun calculateDistance(other: Location): Double
    abstract fun ifKnownOrElse(knownAction: (Location) -> Unit,
        unknownAction: () -> Unit)
}

class EarthLocation(val latitude: Double, val longitude: Double): 
  Location() {
    override fun calculateDistance(other: Location): Double {
        val earthRadius = 6371.0
        val latDistance = Math.toRadians(
            latitude - (other as EarthLocation).latitude)
        val lngDistance = Math.toRadians(
            longitude - other.longitude)
        val a = sin(latDistance / 2) * sin(latDistance / 2) +
          cos(Math.toRadians(latitude)) * 
          cos(Math.toRadians(other.latitude)) *
          sin(lngDistance / 2) * sin(lngDistance / 2)
        val c = 2 * atan2(sqrt(a), sqrt(1 - a))
        return earthRadius * c
}
    
    override fun ifKnownOrElse(knownAction: 
      (Location) -> Unit, unknownAction: () -> Unit) {
        knownAction(this)
    }
}

class UnknownLocation : Location() {
    override fun calculateDistance(other: Location): Double {
        throw IllegalArgumentException(
            "Can't calculate distance" +
            " from an unknown location.")
    }

    override fun ifKnownOrElse(knownAction:
        (Location) -> Unit, unknownAction: () -> Unit) {
            unknownAction()
    }
}

class Person(val name: String, val location: Location)

fun main() {
    val people = listOf(
        Person("Alice", EarthLocation(40.7128, -74.0060)), 
        // New York City
        Person("Bob", EarthLocation(51.5074, -0.1278)), 
        // London
        Person("Charlie", EarthLocation(48.8566, 2.3522)),
        // Paris
        Person("Tony", UnknownLocation()) 
        // Unknown location
    )
    val rio = EarthLocation(-22.9068, -43.1729)
    // Rio de Janeiro coordinates

    for (person in people) {
          person.location.ifKnownOrElse(
              { location -> println("${person.name} is " +
                  "${location.calculateDistance(rio)} kilometers " +
                  "from Rio.") },
              { println("${person.name} is at an unknown " +
                  "location.") }
          )
      }
}

Detection 🔍

[X] Semi-Automatic

You can check for special numbers used as nulls

Tags 🏷️

Null

Level 🔋

[X] Intermediate

Why the Bijection Is Important 🗺️

Real coordinates map to real places on Earth. That is the bijection between your model and the MAPPER.

When you reuse (0, 0) to mean "unknown location," you collapse two different concepts into a single representation.

A real point in the Atlantic Ocean and the absence of data aren't the same thing, and your model shouldn't pretend they are.

Modeling the unknown location as its own type keeps the mapping honest.

Real coordinates always mean a real place, and missing data gets its own explicit representation instead of borrowing one that already means something else.

AI Generation 🤖

AI generators create this smell often.

When you ask for a location class, they default to primitive latitude and longitude doubles and reach for (0.0, 0.0) as a convenient placeholder for missing data, the same shortcut developers take under deadline pressure.

AI Detection 🧲

AI generators rarely catch this smell on their own.

Unless you explicitly ask for a type that represents unknown locations, they treat (0.0, 0.0) as a normal default value and won't suggest polymorphism unless you request it.

Try Them! 🛠

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Replace the (0.0, 0.0) sentinel value with a polymorphic Location type that separates known coordinates from an explicit unknown location

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion 🏁

Don't use Null to represent real objects

Relations 👩❤️💋👨

https://coderlegion.com/9248/code-smell-12-null

https://maximilianocontieri.com/code-smell-126-fake-null-object

https://maximilianocontieri.com/code-smell-160-invalid-id-9999

More Information 📕

https://coderlegion.com/6462/null-the-billion-dollar-mistake

https://en.wikipedia.org/wiki/Null_Island

A research buoy once sat right at 0°N 0°E collecting climate data until 2021, and the exact antipode of Null Island, at 0°N 180°E, is nicknamed "Antinull Island."

https://www.youtube.com/v/daiCb6pT1qY

Disclaimer 📘

Code Smells are my opinion.

The billion dollar mistake of having null in the language. And since JavaScript has both null and undefined, it's the two billion dollar mistake.

Anders Hejlsberg

https://coderlegion.com/13786/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

Code Smell 320 - Vanity Coverage

Wed, 24 Jun 2026 00:20:26 +0000

Brushing Over Real Problems

TL;DR: You write tests that touch every line but verify nothing, creating false confidence in a broken system.

Problems 😔

False confidence
Hidden production defects
Misleading metrics
Wasted test effort
Untested edge cases

Solutions 😃

Use mutation testing
Test real behaviors
Write assertive tests
Delete coverage-only tests

Refactorings ⚙️

https://coderlegion.com/20855/refactoring-011-replace-comments-with-tests

Context 💬

Many teams set a coverage threshold: 80%, 90%, or even 100%.

When you chase that number, you write tests that call methods without checking the actual results.

A test that calls calculateTax() but only asserts result is not None executes the line.

It doesn't verify the tax calculation is correct.

The dashboard turns green.

Defects survive in production.

This is vanity coverage: cosmetic metrics that hide real problems. Like brushes that make surfaces look smooth while the rot stays underneath.

Mutation testing reveals the truth.

When you mutate production code and no tests fail, your coverage numbers lied.

Sample Code 💻

Wrong 🚫

describe('BankAccount', () => {
  test('deposit', () => {
    const account = new BankAccount(100);
    account.deposit(50);
    // Only checking it didn't crash
    expect(account).toBeDefined();
  });

  test('withdraw', () => {
    const account = new BankAccount(100);
    const result = account.withdraw(30);
    // No assertion about the result!
  });

  test('transfer', () => {
    const source = new BankAccount(200);
    const target = new BankAccount(0);
    // Just calling the method to "cover" the line
    source.transfer(50, target);
  });
});

Right 👉

describe('BankAccount', () => {
  test('deposit increases balance', () => {
    const account = new BankAccount(100);
    account.deposit(50);
    expect(account.balance()).toBe(150);
  });

  test('withdraw decreases balance', () => {
    const account = new BankAccount(100);
    account.withdraw(30);
    expect(account.balance()).toBe(70);
  });

  test('withdraw raises on insufficient funds', () => {
    const account = new BankAccount(50);
    expect(() => account.withdraw(100))
      .toThrow(InsufficientFundsError);
  });

  test('transfer moves money between accounts', () => {
    const source = new BankAccount(200);
    const target = new BankAccount(0);
    source.transfer(50, target);
    expect(source.balance()).toBe(150);
    expect(target.balance()).toBe(50);
  });
});

Detection 🔍

[X] Semi-Automatic

Run a mutation testing tool (PIT for Java, Stryker for JavaScript, mutmut for Python).

Count the surviving mutants.

If coverage is high but mutants survive, you have vanity coverage.

You can also search for assertion-free tests, single assertNotNull() assertions, or tests that still pass after you delete the entire production method body.

Exceptions 🛑

Smoke tests that call endpoints to verify the system starts are acceptable without detailed assertions.

These work when they complement a real test suite, not replace it.

Tags 🏷️

Testing

Level 🔋

[x] Intermediate

Why the Bijection Is Important 🗺️

Your test suite must map each test to a real behavior in the MAPPER.

When a test covers a line without verifying observable behavior, you break that bijection.

Coverage tools only measure "lines executed."

Chase the number without bijection and your suite looks complete while missing real requirements entirely.

AI Generation 🤖

AI code generators sometimes produce vanity coverage.

Ask one to "add tests to reach 80% coverage," and it writes tests that call methods and assert trivially true facts.

The metric goes up.

Nothing gets verified.

AI Detection 🧲

AI can detect vanity coverage, but only if you ask the right questions.

Try: "Find tests with no real assertions" or "Find tests that pass when I delete the production method body."

Without those prompts, most AI tools see a green test and call it good.

Try Them! 🛠

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Replace vanity coverage tests with tests that verify real behaviors and fail when production code is wrong

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion 🏁

Coverage is a signal, not a goal.

When you treat it as a goal, you create vanity coverage that hides real defects.

Use mutation testing to discover what your suite actually verifies.

Write tests that describe real behaviors, not tests that execute lines.

Relations 👩❤️💋👨

https://maximilianocontieri.com/code-smell-104-assert-true

https://maximilianocontieri.com/code-smell-76-generic-assertions

https://maximilianocontieri.com/code-smell-175-changes-without-coverage

https://maximilianocontieri.com/code-smell-30-mocking-business

https://maximilianocontieri.com/code-smell-203-irrelevant-test-information

More Information 📕

https://en.wikipedia.org/wiki/Mutation_testing

https://martinfowler.com/bliki/TestCoverage.html

https://stryker-mutator.io/

Quote

The most dangerous kind of waste is the waste we don't recognize.

Shigeo Shingo

Disclaimer 📘

Code Smells are my opinion.

Credits 🙏

Photo by Jamie Street on Unsplash

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

Code Smell 319 - Hardcoded Stateless Properties

Fri, 10 Apr 2026 02:01:39 +0000

Don't turn collaborators into permanent roommates

TL;DR: You should avoid storing stateless utility classes as instance variables initialized with new.

Problems

Hardcoded dependencies
Testing difficulties
High coupling
Hidden side effects
Rigid design
Misleading intent
Premature Optimization
Stack clutter

Solutions

Use dependency injection
Pass as parameter
Use static methods
Inline the logic
Use local variables
Inline object creation

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-024-replace-global-variables-with-dependency-injection

https://maximilianocontieri.com/refactoring-030-inline-attributes

https://coderlegion.com/13328/refactoring-007-extract-class

Context

Hardcoding a stateless class in the constructor creates permanent coupling.

Even if the class is cheap to instantiate, you lose the ability to swap it.

Stateless objects shouldn't be part of the object's internal state.

You confuse readers by making a tool look essential to the object's identity.

It makes testing harder because you can't mock the hardcoded dependency.

Sample Code

Wrong

class UserProcessor {
  private provider: MockDataProvider;

  constructor() {
    // You hardcode the dependency here.
    // This makes the class harder to test.
    this.provider = new MockDataProvider();
  }

  process(data: any) {
    return this.provider.format(data);
  }
}

Right

interface DataProvider {
  format(data: any): any;
}

class UserProcessor {
  // You inject the dependency via constructor.
  // Now you can swap it or mock it easily.
  constructor(private readonly provider: DataProvider) {}

  process(data: any) {
    return this.provider.format(data);
  }
}

// Simpler but coupled
 class UserProcessor {
    constructor() {
      // Empty
    }
  
    process(data: any) {
      return new MockDataProvider().format(data);
    }
  }

Detection

Look for the new keyword inside constructors.

Watch for private properties instantiated directly in the constructor rather than passed as parameters.

Most linters flag this pattern automatically when you create instances and assign them to private fields.

Tags ️

Premature Optimization

Level

[X] Beginner

Why the Bijection Is Important ️

Software should mimic a MAPPER of the real world.

In reality, a worker might use a tool to complete a task.

The tool is not a permanent physical attachment to the worker.

When you refactor to use dependency injection, you respect the bijection by treating collaborators as external entities, not internal state.

This keeps your simulation flexible and accurate.

AI Generation

AI generators frequently create this smell.

They often suggest code that just works by instancing dependencies directly in the constructor to save time.

AI Detection

AI can easily detect this smell without explicit instructions.

When you show AI a class with new keywords in the constructor, it recognizes the pattern as hardcoded coupling.

AI identifies that stateless utility classes should be injected rather than instantiated internally.

The detection is straightforward because the pattern is syntactically obvious and semantically harmful.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: remove the cached attribute

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Storing stateless dependencies as instance variables makes your code rigid.

When you inject these dependencies instead, you improve testability and keep your objects focused on their true purpose.

Relations ❤️

https://coderlegion.com/8216/code-smell-06-too-clever-programmer

https://maximilianocontieri.com/code-smell-20-premature-optimization

More Information

https://coderlegion.com/6634/coupling-the-one-and-only-software-design-problem

Disclaimer

Code Smells are my opinion.

Credits

Photo by Possessed Photography on Unsplash

Coupling is the enemy of change

Rich Hickey

https://coderlegion.com/13786/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

Code Smell 17 - Global Functions

Sat, 28 Feb 2026 15:57:25 +0000

Discouraged by Object-Oriented Programming, Many mixed languages support it. And developers abuse them.

TL;DR: Global functions bring a lot of coupling. Don't use them.

Problems

Tight Coupling
Poor Readability
Maintainability
Testability
Hidden side-effects

Solutions

Wrap the function in a context object.

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-007-extract-class

https://maximilianocontieri.com/refactoring-010-extract-method-object

https://maximilianocontieri.com/refactoring-020-transform-static-functions

https://maximilianocontieri.com/refactoring-024-replace-global-variables-with-dependency-injection

Examples

External Resources Access, Database access, Time and Operating System resources.

Context

When you place a function in the global scope, you allow any part of your system to access it at any time.

This sounds convenient, but it creates a web of invisible connections.

If you want to change how that function works, you must check every corner of your application.

This practice also makes testing nearly impossible.

When a method calls a global function like getSystemTime() or saveToDatabase(), you cannot easily replace that function with a mock or a fake version during a test.

You end up testing the entire environment instead of just your logic.

Sample Code

Wrong

<?

class Employee {
    function taxesPayedUntilToday() {
        return database()->select(
            "SELECT TAXES FROM EMPLOYEE".
            " WHERE ID = " . $this->id() .
            " AND DATE < " . currentDate());
    }
}

Right

<?

final class EmployeeTaxesCalculator {
    function taxesPayedUntilToday($context) {
        return $context->SelectTaxesForEmployeeUntil(
            $this->ssn,
            $context->currentDate());
    }
}

Detection

Many modern languages avoid them. For the permissive ones, scope rules can be applied and automatically checked.

Exceptions

Some languages use global functions as their core library (like str_len in C or some PHP functions).

In these cases, you might wrap them in your own objects to improve testability, but the functions themselves are part of the platform.

Tags ️

Globals

Level

[x] Beginner

Why the Bijection Is Important ️

In the MAPPER, objects have responsibilities and specific contexts.

A Global Function doesn't exist in a real-world simulation because every action belongs to an actor or a component.

When you use global functions, you break the bijection between your code and the entities you model.

You create a God-like action that exists nowhere and everywhere at the same time.

AI Generation

AI tools often suggest global functions because they look for the shortest code path.

They frequently provide utility snippets that live in the global scope because they don't know the specific architecture of your project.

AI Detection

You can ask an AI to "Refactor these global functions into domain objects" or "Apply dependency injection to remove global scope dependencies."

Many AI models are very good at identifying which class should own a specific logic.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Take these global functions and group them into logical context objects. Use dependency injection so I can test the classes that use them.

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Structured programming considers global functions harmful. Yet, we can observe some bad practices cross paradigm boundaries.

Singleton and Classes are global points of access.

Relations ❤️

https://maximilianocontieri.com/code-smell-60-global-classes

https://coderlegion.com/6959/singleton-the-root-of-all-evil

https://maximilianocontieri.com/code-smell-22-helpers

https://maximilianocontieri.com/code-smell-209-side-effects

More Information

https://en.wikipedia.org/wiki/Global_variable

Credits

Photo by Mae Mu on Unsplash

The road to programming hell is paved with global variables.

Steve McConnell

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

Code Smell 16 - Ripple Effect

Fri, 20 Feb 2026 00:25:46 +0000

Small changes yield unexpected problems.

TL;DR: If small changes have big impact, you need to decouple your system.

Problems

High Coupling
Low maintainability
Side effects
High risk
Testing difficulty

Solutions

Decouple your components.
Cover with tests.
Refactor and isolate what is changing.
Depend on interfaces.

https://maximilianocontieri.com/how-to-decouple-a-legacy-system

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-007-extract-class

https://maximilianocontieri.com/refactoring-024-replace-global-variables-with-dependency-injection

Examples

Legacy Systems

Context

The ripple effect happens when you design a system where objects know too much about each other.

When you modify a specific behavior, the impact spreads through the codebase like a stone thrown into a pond.

You feel this pain when a simple requirement change requires you to touch dozens of files.

Your classes have direct dependencies on concrete implementations rather than abstractions.

Sample Code

Wrong

class Time {
   constructor(hour, minute, seconds) {
     this.hour = hour;    
     this.minute = minute;  
     this.seconds = seconds;  
  }
    now() {
      // call operating system
    }  
}

// Adding a TimeZone will have a big Ripple Effect
// Changing now() to consider timezone will also bring the effect

Right

class Time {
   constructor(hour, minute, seconds, timezone) {
     this.hour = hour;    
     this.minute = minute;  
     this.seconds = seconds;  
     this.timezone = timezone;  
  }  
  // Removed now() since is invalid without context
}

class RelativeClock {
   constructor(timezone) {
     this.timezone = timezone;
   }
   now(timezone) {
     var localSystemTime = this.localSystemTime();
     var localSystemTimezone = this.localSystemTimezone();
     // Do some math translating timezones
     // ...
     return new Time(..., timezone);     
   }  
}

Detection

It is not easy to detect problems before they happen.

Mutation Testing and root cause analysis of single points of failures may help.

Tags ️

Coupling

Level

[x] Intermediate

Why the Bijection Is Important ️

In a proper bijection, a change in a single real-world concept should only lead to a change in a single program component.

When you break the MAPPER , one concept spreads across your code.

This creates the ripple effect because you didn't represent the original idea as a single, isolated unit.

AI Generation

AI generators often create this smell because they suggest "quick fixes" that access global states or direct dependencies.

They focus on making the local code work without seeing the architectural ripple they cause elsewhere.

AI Detection

AI can fix this if you provide the context of the related classes.

When you ask an AI to "decouple these two classes using dependency injection," it usually does a great job of breaking the link.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Refactor this class to remove direct dependencies on global objects. Use constructor-based dependency injection and depend on interfaces or abstractions instead of concrete implementations.

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

There are multiple strategies to deal with Legacy and coupled systems.

You should deal with this problem before it explodes under your eyes.

Relations ❤️

https://maximilianocontieri.com/code-smell-08-long-chains-of-collaborations

https://maximilianocontieri.com/code-smell-176-changes-in-essence

More Information

https://maximilianocontieri.com/how-to-decouple-a-legacy-system

Credits

Photo by Jack Tindall on Unsplash

Architecture is the tension between coupling and cohesion.

Neal Ford

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://coderlegion.com/10942/how-to-find-the-stinky-parts-of-your-code

How to Find the Stinky Parts of Your Code

Mon, 02 Feb 2026 16:28:10 +0000

The code smells badly. Let's see how to change the aromas.

TL;DR: A Compilation of bad smells in code.

In this series, we will see several symptoms and situations that make us doubt the quality of our development. We will present possible solutions.

Most of these smells are just hints of something that might be wrong. They are not rigid rules.

Code Smells

https://coderlegion.com/7246/code-smell-01-anemic-models

https://coderlegion.com/7475/code-smell-02-constants-and-magic-numbers

https://coderlegion.com/7617/code-smell-03-functions-are-too-long

https://coderlegion.com/7929/code-smell-04-string-abusers

https://coderlegion.com/8106/code-smell-05-comment-abusers

https://coderlegion.com/8216/code-smell-06-too-clever-programmer

https://coderlegion.com/9110/code-smell-07-boolean-variables

https://maximilianocontieri.com/code-smell-08-long-chains-of-collaborations

https://coderlegion.com/8495/code-smell-09-dead-code

https://coderlegion.com/8662/code-smell-10-too-many-arguments

https://maximilianocontieri.com/code-smell-11-subclassification-for-code-reuse

https://coderlegion.com/9248/code-smell-12-null

https://coderlegion.com/9517/code-smell-13-empty-constructors

https://coderlegion.com/10362/code-smell-14-god-objects

... and many more to come.

Photo by Richard Ecsedi on Unsplash

Smells are certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring

Martin Fowler

https://maximilianocontieri.com/software-engineering-great-quotes

Part of the objective of this series is to generate spaces for debate and discussion on software design.

https://coderlegion.com/6864/object-design-checklist

We look forward to your comments and suggestions on this article.

Code Smell 15 - Missed Preconditions

Sat, 31 Jan 2026 00:51:20 +0000

Assertions, Preconditions, Postconditions and invariants are our allies to avoid invalid objects. Avoiding them leads to hard-to-find errors.

TL;DR: If you turn off your assertions just in production your phone will ring at late hours.

Problems

Consistency
Contract breaking
Hard debugging
Late failures
Bad cohesion

Solutions

Create strong preconditions
Raise exceptions
Use Fail-Fast principle
Defensive Programming
Enforce object invariants
Avoid anemic models

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-016-build-with-the-essence

https://maximilianocontieri.com/refactoring-035-separate-exception-types

Examples

Constructors are an excellent first line of defense.
Anemic Objects lack these rules.
DTOs are also a common mistake in the industry.

Context

You often assume that "someone else" checked the objects before it reached your function.

This assumption is a trap. When you create objects without enforcing their internal rules, you create "Ghost Constraints."

These are rules that exist in your mind but not in the code.

If you allow a "User" object to exist without an email or a "Transaction" to have a negative amount, you create a time bomb.

The error won't happen when you create the object; it will happen much later when you try to use it.

This makes finding the root cause very difficult.

You must ensure that once you create an object, it remains valid from the very birth throughout its entire lifecycle.

Sample Code

Wrong

class Date:
  def __init__(self, day, month, year):
    self.day = day
    self.month = month
    self.year = year

  def setMonth(self, month):
    self.month = month

startDate = Date(3, 11, 2020)
# OK

startDate = Date(31, 11, 2020)
# Should fail

startDate.setMonth(13)
# Should fail

Right

class Date:
  def __init__(self, day, month, year):
  if month > 12:
    raise Exception("Month should not exceed 12")
    #
    # etc ...
  
    self._day = day
    self._month = month
    self._year = year
 
startDate = Date(3, 11, 2020)
# OK

startDate = Date(31, 11, 2020)
# fails

startDate.setMonth(13)
# fails since invariant makes object immutable

Detection

It's difficult to find missing preconditions, as long with assertions and invariants.

Tags ️

Fail-Fast

Level

[x] Beginner

Why the Bijection Is Important ️

In the MAPPER, a person cannot have a negative age or an empty name.

If your code allows these states, you break the bijection.

When you maintain a strict one-to-one relationship between your business rules and your code, you eliminate a whole category of "impossible" defects.

AI Generation

AI generators often create "happy path" code.

They frequently skip validations to keep the examples short and concise.

You must explicitly ask them to include preconditions.

AI Detection

AI tools are great at spotting missing validations.

If you give them a class and ask "What invariants are missing here?", they usually find the missing edge cases quickly.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Add constructor preconditions to this class to ensure it never enters an invalid state based on real-world constraints. Fail fast if the input is wrong.

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Always be explicit on object integrity.

Turn on production assertions.

Yes, even if it means taking a small performance hit.

Trust me, tracking down object corruption is way harder than preventing it upfront.

Embracing the fail-fast approach isn't just good practice - it's a lifesaver.

https://coderlegion.com/7024/fail-fast-principle

Relations ❤️

https://coderlegion.com/7246/code-smell-01-anemic-models

https://maximilianocontieri.com/code-smell-189-not-sanitized-input

https://maximilianocontieri.com/code-smell-40-dtos

More Information

https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction

Credits

Photo by Jonathan Chng on Unsplash

Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration) chip, bridge, engine...) without a spec. No professional engineer would even consider the idea.

Bertrand Meyer

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 14 - God Objects

Fri, 23 Jan 2026 13:12:23 +0000

An object that knows too much or does too much.

TL;DR: Don't take too many responsibilities in a single class.

Problems

Low cohesion
High coupling
Single Responsibility Violation

Solutions

Split responsibilities.
Follow the Single Responsibility Principle.
Apply the Boy Scout Rule.

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-007-extract-class

https://maximilianocontieri.com/refactoring-002-extract-method

Examples

Libraries

Context

God Objects form when you concentrate too many responsibilities in a single class.

These objects become central hubs that know everything and control everything in your system.

You create them gradually, with each added method making the class harder to maintain.

Libraries and utility classes from procedural programming encouraged this pattern in the 1960s.

Object-oriented design distributes responsibilities across many focused objects.

Sample Code

Wrong

class Soldier {
   run() {}
   fight() {}
   driveGeneral() {}
   clean() {} 
   fire() {} 
   bePromoted() {}
   serialize() {}
   display() {} 
   persistOnDatabase() {}
   toXML() {}
   jsonDecode() {}
  
  // ...
  }

Right

class Soldier {
   run() {}
   fight() {}
   clean() {}    
  }

Detection

Linters can count methods and warn against a threshold.

Exceptions

Facades

Tags ️

Coupling

Level

[X] Beginner

Why the Bijection Is Important ️

When you model your software, you need to maintain a clear bijection between your code and the MAPPER.

God Objects break this mapping by lumping multiple real-world concepts into a single artificial construct.

You will not find a single entity that manages users, processes payments, sends emails, and generates reports.

You have distinct roles and responsibilities.

When you create a God Object, you lose this clear correspondence, making your code harder to understand and maintain.

AI Generation

AI code generators frequently create God Objects when you ask them to "create a complete system" or "build a payment system.".

They tend to group related functionality into convenient single classes rather than distributing responsibilities properly.

You need to explicitly instruct them to separate concerns and create focused classes.

AI Detection

AI tools can detect God Objects when you provide clear instructions.

The assistants can count methods, analyze dependencies, and suggest splitting classes.

They struggle to determine the right boundaries without domain knowledge about your specific system.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Suggest how to split it into smaller, cohesive classes, each handling a single responsibility

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Libraries were fine in the 1960s.

In Object-Oriented Programming, you need to distribute responsibilities among many objects.

Relations ❤️

https://maximilianocontieri.com/code-smell-34-too-many-attributes

https://maximilianocontieri.com/code-smell-202-god-constant-class

https://maximilianocontieri.com/code-smell-124-divergent-change

https://maximilianocontieri.com/code-smell-22-helpers

https://maximilianocontieri.com/code-smell-143-data-clumps

More Information

https://en.wikipedia.org/wiki/God_object

https://refactoring.guru/es/smells/large-class

https://coderlegion.com/6634/coupling-the-one-and-only-software-design-problem

Also Known as

Large Class

Credits

Photo by Francisco Ghisletti on Unsplash

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 13 - Empty Constructors

Sat, 10 Jan 2026 23:04:37 +0000

Non-Parameterized constructors are a code smell of an invalid object that will dangerously mutate. Incomplete objects cause lots of issues.

TL;DR: Pass the essence to all your objects so they will not need to mutate.

Problems

Mutability
Incomplete objects
Concurrency inconsistencies between creation and essence setting.
Setters

Solutions

Pass the object's essence on creation
Create objects with their immutable essence.

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-001-remove-setters

https://maximilianocontieri.com/refactoring-016-build-with-the-essence

Examples

Some persistence frameworks in static typed languages require an empty constructor.

Sample Code

Wrong

class AirTicket {
   constructor() {     
  }
}

Right

class AirTicket {
   constructor(origin,
                destination, 
                arline,
                departureTime,
                passenger) {     
     
  // ...
  }
}

Detection

Any linter can warn this (possible) situation.

Exceptions

Stateless objects. Always better solution than static class methods.

Tags ️

Anemic Models

Level

[X] Beginner

Why the Bijection Is Important

In the MAPPER, objects correspond to real-world entities.

Real people aren't born nameless and formless, then gradually acquire attributes.

You don't meet someone who temporarily has no age or email address.

When you model a person, you should capture their essential attributes at birth, just like reality.

Breaking this bijection by creating hollow objects forces you to represent impossible states.

Empty constructors create phantom and invalid objects that don't exist in your domain model, violating the mapping between your code and reality.

AI Generation

AI code generators frequently produce this smell because they often follow common ORM patterns.

When you prompt AI to "create a Person class," it typically generates empty constructors with getters and setters.

AI tools trained on legacy codebases inherit these patterns and propagate them unless you explicitly request immutable objects with required constructor parameters.

AI Detection

AI tools can detect and fix this smell when you provide clear instructions.

You need to specify that objects should be immutable with required constructor parameters.

Without explicit guidance, AI tools may not recognize empty constructors as problematic since they appear frequently in training data.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Create an immutable class with required information. Include constructor validation and no setters. Make all fields final and use constructor parameters only

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Always create complete objects. Make their essence immutable to endure through time.

Every object needs its essence to be a valid one since inception.

We should read Plato's ideas about immutability and create entities in a complete and immutable way.

These immutable objects favor bijection and survive the passing of time.

Relations ❤️

https://coderlegion.com/7246/code-smell-01-anemic-models

https://maximilianocontieri.com/code-smell-28-setters

https://maximilianocontieri.com/code-smell-40-dtos

https://coderlegion.com/8662/code-smell-10-too-many-arguments

https://maximilianocontieri.com/code-smell-116-variables-declared-with-var

More Information

https://codexposed.hashnode.dev/constructors-demystified

https://coderlegion.com/6742/the-evil-power-of-mutants

https://coderlegion.com/8662/code-smell-10-too-many-arguments

Credits

Photo by Brett Jordan in Pexels

In a purely functional program, the value of a [constant] never changes, and yet, it changes all the time! A paradox!

Joel Spolski

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 12 - Null

Sun, 04 Jan 2026 13:30:27 +0000

Programmers use Null as different flags. It can hint at an absence, an undefined value, en error etc. Multiple semantics lead to coupling and defects.

TL;DR: Null is schizophrenic and does not exist in real-world. Its creator regretted and programmers around the world suffer from it. Don't be a part of it.

Problems

Coupling between callers and senders.
If/Switch/Case Polluting.
Null is not polymorphic with real objects. Hence, Null Pointer Exception
Null does not exist on real-world. Thus, it violates Bijection Principle

Solutions

Avoid Null.
Use the NullObject pattern to avoid ifs.
Use Optionals.

https://coderlegion.com/6462/null-the-billion-dollar-mistake

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-015-remove-null

https://maximilianocontieri.com/refactoring-029-replace-null-with-collection

https://maximilianocontieri.com/refactoring-014-remove-if

Context

When you use null, you encode multiple meanings into a single value.

Sometimes you want to represent an absence.

Sometimes you mean you have not loaded your objects yet.

Sometimes you mean error.

Callers must guess your intent and add conditionals to protect themselves.

You spread knowledge about internal states across your codebase.

Sample Code

Wrong

class CartItem {
    constructor(price) {
        this.price = price;
    }
}

class DiscountCoupon {
    constructor(rate) {
        this.rate = rate;
    }
}

class Cart {
    constructor(selecteditems, discountCoupon) {
        this.items = selecteditems;
        this.discountCoupon = discountCoupon;
    }

    subtotal() {
        return this.items.reduce((previous, current) => 
            previous + current.price, 0);
    }

    total() {
        if (this.discountCoupon == null)
            return this.subtotal();
        else
            return this.subtotal() * (1 - this.discountCoupon.rate);
    }
}

cart = new Cart([
    new CartItem(1),
    new CartItem(2),
    new CartItem(7)
    ], new DiscountCoupon(0.15)]);
// 10 - 1.5 = 8.5

cart = new Cart([
    new CartItem(1),
    new CartItem(2),
    new CartItem(7)
    ], null);
// 10 - null  = 10

Right

class CartItem {
    constructor(price) {
        this.price = price;
    }
}

class DiscountCoupon {
    constructor(rate) {
        this.rate = rate;
    }

    discount(subtotal) {
        return subtotal * (1 - this.rate);
    }
}

class NullCoupon {
    discount(subtotal) {
        return subtotal;
    }
}

class Cart {
    constructor(selecteditems, discountCoupon) {
        this.items = selecteditems;
        this.discountCoupon = discountCoupon;
    }

    subtotal() {
        return this.items.reduce(
            (previous, current) => previous + current.price, 0);
    }

    total() {
        return this.discountCoupon.discount(this.subtotal());
    }
}

cart = new Cart([
    new CartItem(1),
    new CartItem(2),
    new CartItem(7)
    ], new DiscountCoupon(0.15));
// 10 - 1.5 = 8.5

cart = new Cart([
    new CartItem(1),
    new CartItem(2),
    new CartItem(7)
    ], new NullCoupon());
// 10 - nullObject = 10

Detection

Most Linters can flag null usages and warn you.

Exceptions

You sometimes need to deal with null when you integrate with databases, legacy APIs, or external protocols.

You must contain null at the boundaries and convert it immediately into meaningful objects.

Tags ️

Null

Level

[x] Intermediate

Why the Bijection Is Important ️

When you use null, you break the bijection between your code and the MAPPER.

Nothing in the mapper behaves like null.

Absence, emptiness, and failure mean different things.

When you collapse them into null, you force your program to guess reality and you invite defects.

AI Generation

AI generators often introduce this smell.

They default to null when they lack context or want to keep examples short and also because it is widespread (but harmful) industry default.

AI Detection

You can instruct AI to remove nulls with simple rules.

When you ask for explicit domain objects and forbid nullable returns, generators usually fix the smell correctly.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Rewrite this code to remove all null returns. Model absence explicitly using domain objects or collections. Do not add conditionals

Conclusion

Null is the billion-dollar mistake. Yet, most program languages support them and libraries suggest its usage.

Relations ❤️

https://maximilianocontieri.com/code-smell-88-lazy-initialization

https://maximilianocontieri.com/code-smell-157-balance-at-0

https://maximilianocontieri.com/code-smell-93-send-me-anything

https://maximilianocontieri.com/how-to-get-rid-of-annoying-ifs-forever

https://maximilianocontieri.com/code-smell-36-switchcaseelseifelseif-statements

https://maximilianocontieri.com/code-smell-149-optional-chaining

https://maximilianocontieri.com/code-smell-212-elvis-operator

https://maximilianocontieri.com/code-smell-192-optional-attributes

https://maximilianocontieri.com/code-smell-126-fake-null-object

https://maximilianocontieri.com/code-smell-208-null-island

https://maximilianocontieri.com/code-smell-160-invalid-id-9999

https://maximilianocontieri.com/code-smell-100-goto

https://maximilianocontieri.com/code-smell-42-warningsstrict-mode-off

https://maximilianocontieri.com/code-smell-23-instance-type-checking

More Information

https://coderlegion.com/6462/null-the-billion-dollar-mistake

Credits

Photo by Kurt Cotoaga on Unsplash

I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Tony Hoare

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 07 - Boolean Variables

Wed, 31 Dec 2025 01:38:55 +0000

Using Boolean variables as flags introduces accidental implementation complexity and pollutes the code with Ifs.

TL;DR: Avoid Boolean variables, they lead to conditional logic and force you to write Ifs. Create polymorphic states instead.

Problems

Extensibility
Comparison in some languages
Missed polymorphism
Limited semantics
Primitive obsession

Solutions

If Boolean maps to a real-world entity is safe.
Model Booleans as a State to favor Extensibility following the Open/Closed Principle.
Create intention-revealing objects
Replace Booleans with polymorphism

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-014-remove-if

Examples

Flags
Status indicators

Context

Boolean variables tempt you to oversimplify complex domains.

When you use a Boolean, you force two states where many might exist.

This creates coupling because you hardcode behavior based on true/false checks scattered throughout your code.

Booleans also hide intent. A variable named flag tells you nothing about what it represents in the real world.

Even descriptive names like isActive or hasPermission leak implementation details instead of revealing domain concepts.

The problems multiply when you need a third state. You cannot extend a Boolean without breaking existing code.

You end up with multiple Boolean combinations that create implicit states, making your code fragile and hard to understand.

Real-world entities rarely have just two states.

A traffic light isn't "on" or "off"—it's red, yellow, or green. An order isn't just "paid" or "unpaid"—it might be pending, processed, shipped, or delivered.

Sample Code

Wrong

<?

function processBatch(
    bool $useLogin,
    bool $deleteEntries,
    bool $beforeToday) {
    // ...
}

Right

<?

function processBatch(
    LoginStrategy $login,
    DeletionPolicy $deletionPolicy,
    Date $cutoffDate) {
    // ...
}

Detection

[X] Manual

Automatic detection can warn for B usage, but this can yield false positives.

You can search for boolean attributes in classes, Boolean parameters in methods, and conditional statements that check Boolean values.

Look for variables with "is", "has", "can", or "flag" in their names.

Watch for multiple Boolean combinations that represent different states.

Exceptions

Real-world true/false rules
Some languages have issues with Boolean comparators.

In these coupled with accidental complexity languages, Booleans are a common error source.

Tags ️

Level

[x ] Intermediate

Why the Bijection Is Important ️

Your code should always mirror reality.

When you use a Boolean to represent an employee's status, you break the bijection between your software and the MAPPER.

Real employees don't have a true/false state. They have concrete statuses like "on vacation" or "working remotely."

This broken mapping creates a gap between how domain experts think and how your code works. Business people talk about "vacation status" or "remote work," not about "is_on_vacation equals true."

When you model with Booleans, you force translation between business language and code, increasing cognitive load and error potential.

The bijection violation compounds when requirements change. Adding a new employee status means modifying all the boolean logic scattered across your codebase.

With proper domain modeling, you simply add a new status class. The broken mapping makes your code rigid where reality is flexible.

AI Generation

AI code generators frequently create Boolean flags because they optimize for brevity and simplicity.

They often suggest is_active or has_permission flags when generating boilerplate code.

You need to explicitly request domain modeling to avoid this pattern.

AI Detection

AI tools can detect Boolean variables with medium accuracy when you provide context.

You need to specify that you want domain-driven design and state pattern usage.

Simple prompts might not catch the smell without explicit instructions to avoid Booleans.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: correct=Replace Boolean variables with polymorphism

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Take extra care when declaring something Boolean.

Flags are difficult to maintain and extend.

Learn more about the domain. Try migrating to state design pattern. Use polymorphism instead of ifs/switch/cases.

Relations ❤️

https://maximilianocontieri.com/code-smell-51-double-negatives

https://maximilianocontieri.com/code-smell-62-flag-variables

https://maximilianocontieri.com/code-smell-104-assert-true

https://maximilianocontieri.com/code-smell-24-boolean-coercions

https://maximilianocontieri.com/code-smell-101-comparison-against-booleans

https://maximilianocontieri.com/code-smell-122-primitive-obsession

https://maximilianocontieri.com/code-smell-199-gratuitous-booleans

https://maximilianocontieri.com/code-smell-270-boolean-apis

More Information

https://martinfowler.com/bliki/FlagArgument.html

Also Known as

Flag Abuser

Credits

Photo by Phil Hearing on Unsplash

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 318 - Refactoring Dirty Code

Sun, 28 Dec 2025 13:55:55 +0000

You polish code that nobody touches while the real hotspots burn

TL;DR: Don't waste time refactoring code that never changes; focus on frequently modified problem areas.

Problems

Wasted effort
Wrong priorities
Missed real issues
Team productivity drop
Resource misallocation
False progress feeling

Solutions

Analyze change frequency
Identify code hotspots
Use version control data
Focus on active areas
Measure code churn

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-021-remove-dead-code

Context

This is the anti code smell.

You come across ugly code with complex conditionals, long functions, and poor naming.

You remember Uncle Bob's motto of leaving the campsite better than when you found it.

Your refactoring instinct kicks in, and you spend days cleaning it up.

You feel productive, but you've been wasting your time.

Bad code is only problematic when you need to change it.

Stable code, even if poorly written, doesn't hurt your productivity.

The real technical debt lies in code hotspots: areas that are both problematic and frequently modified.

Most codebases follow an extreme distribution where 5% of the code receives 90% of the changes.

Without analyzing version control history, you cannot identify which messy code actually matters.

You end up fixing the wrong things while the real problems remain untouched.

You need to address the technical debt by prioritizing code with poor quality and high change frequency.

Everything else is premature optimization disguised as craftsmanship.

Sample Code

Wrong ❌

# This authentication module hasn't changed in 3 years
# It's deprecated and will be removed next quarter
# But you spend a week "improving" it

class LegacyAuthenticator:
    def authenticate(self, user, pwd):
        # Original messy code from 2019
        if user != None:
            if pwd != None:
                if len(pwd) > 5:
                    # Complex nested logic...
                    result = self.check_db(user, pwd)
                    if result == True:
                        return True
                    else:
                        return False
        return False

# After your "refactoring" (that nobody asked for):
class LegacyAuthenticator:
    def authenticate(self, user: str, pwd: str) -> bool:
        if not self._is_valid_input(user, pwd):
            return False
        return self._verify_credentials(user, pwd)
    
    def _is_valid_input(self, user: str, pwd: str) -> bool:
        return user and pwd and len(pwd) > 5
    
    def _verify_credentials(self, user: str, pwd: str) -> bool:
        return self.check_db(user, pwd)

# Meanwhile, the actively developed payment module
# (modified 47 times this month) remains a mess

Right

# You analyze git history first:
# git log --format=format: --name-only | 
# grep -E '\.py$' | sort | uniq -c | sort -rn

# Results show PaymentProcessor changed 47 times this month
# And it does not have good enough coverage
# LegacyAuthenticator: 0 changes in 3 years

# Focus on the actual hotspot:
class PaymentProcessor:
    # This gets modified constantly and is hard to change
    # REFACTOR THIS FIRST
    def process_payment(self, amount, card, user, promo_code,
                       installments, currency, gateway):
        # 500 lines of tangled logic here
        # Changed 47 times this month
        # Every change takes 2+ days due to complexity
        pass

# Ignore stable legacy code
# But you can use IA to cover existing functionality
# With acceptance tests validated by a human product owner

class LegacyAuthenticator:
    # Leave this ugly code alone
    # It works, it's stable, it's being deprecated
    # Your time is better spent elsewhere
    def authenticate(self, user, pwd):
        if user != None:
            if pwd != None:
                if len(pwd) > 5:
                    result = self.check_db(user, pwd)
                    if result == True:
                        return True
        return False

Detection

[X] Semi-Automatic

You can detect this smell by analyzing your version control history.

Track which files change most frequently and correlate that with code quality metrics.

Tools like CodeScene, git log analysis, or custom scripts can show your actual hotspots.

Track your defects to the code you change more often.

Exceptions

Sometimes you must refactor stable code when:

New feature development requires adaptive changes
Security vulnerabilities require fixes
Regulatory compliance demands changes
You're about to reactivate dormant features

The key is intentional decision-making based on real data, not assumptions.

Tags ️

Technical Debt

Level

[X] Intermediate

Why the Bijection Is Important ️

While you build a MAPPER between your code and real-world behavior, you will notice some parts of your system are more actively changed than others.

Your bijection should reflect this reality.

When you refactor stable code, you break the correspondence between development effort and actual business value.

You treat all code equally in your mental model, but the real world shows extreme usage patterns where a small percentage of code handles the vast majority of changes.

You optimize for an imaginary world where all code matters equally.

AI Generation

Some code generators suggest refactorings without considering change frequency.

AI tools and linters analyze code statically and recommend improvements based on patterns alone, not usage.

They do not access your version control history to understand which improvements actually matter unless you explicitly tell them to do it.

AI might flag every long function or complex conditional, treating a dormant 500-line legacy method the same as an equally messy function you modify daily.

AI Detection

AI can help you to fix this code smell if you provide it with proper context.

You need to give it version control data showing change frequencies. Without that information, AI will make the same mistakes humans do: recommending refactorings based purely on code structure.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Analyze this codebase's git history to identify files with high change frequency. Then review code quality metrics for those files. Recommend refactoring only the intersection of high-churn and low-quality code. Ignore stable low-quality code."

Conclusion

You cannot improve productivity by polishing code that never changes.

Technical debt only matters when it slows you down, which happens in code you actually modify.

Focus your refactoring efforts where they multiply your impact: the hotspots where poor quality meets frequent change.

Everything else is procrastination disguised as engineering excellence.

Let stable ugly code rest in peace.

Your human time is too valuable to waste on problems that don't exist.

Relations ❤️

https://coderlegion.com/8216/code-smell-06-too-clever-programmer

https://maximilianocontieri.com/code-smell-20-premature-optimization

https://maximilianocontieri.com/code-smell-148-todos

https://coderlegion.com/7617/code-smell-03-functions-are-too-long

https://maximilianocontieri.com/code-smell-36-switchcaseelseifelseif-statements

https://maximilianocontieri.com/code-smell-60-global-classes

More Information

https://www.youtube.com/v/F5WkftHqexQ

Disclaimer

Code Smells are my opinion.

Credits

Photo by Viktor Keri on Unsplash

The first rule of optimization is: Don't do it. The second rule is: Don't do it yet.

Michael A. Jackson

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 10 - Too Many Arguments

Sun, 21 Dec 2025 01:26:55 +0000

Objects or Functions need too many arguments to work.

TL;DR: Don't pass more than three arguments to your functions.

Problems

Low maintainability
Low Reuse
Coupling

Solutions

Find cohesive relations among arguments
Create a "context".
Consider using a Method Object Pattern.
Avoid "basic" Types: strings, arrays, integers, etc. Think on objects.

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-007-extract-class

https://maximilianocontieri.com/refactoring-010-extract-method-object

https://maximilianocontieri.com/refactoring-034-reify-parameters

Context

When you add arguments to make a function work, you encode knowledge in position and order.

You force your callers to remember rules that belong to the domain.

When you do this, you move behavior away from meaningful objects, and you replace intent with mechanics.

Sample Code

Wrong

public class Printer {   
  void print(String documentToPrint, 
           String papersize,
           String orientation, 
           boolean grayscales,
           int pagefrom,
           int pageTo,
           int copies,
           float marginLeft,
           float marginRight,
           float marginTop,
           float marginBottom         
        ) {
    }
}

Right

final public class PaperSize { }
final public class Document { }
final public class PrintMargins { }
final public class PrintRange { }  
final public class ColorConfiguration { }
final public class PrintOrientation { }
// Class definition with methods and properties omitted for simplicity

final public class PrintSetup {
    public PrintSetup(PaperSize papersize,
           PrintOrientation orientation, 
           ColorConfiguration color,
           PrintRange range,
           int copiesCount,
           PrintMargins margins
           ) {}
}

final public class Printer {   
  void print(
         Document documentToPrint, 
         PrintSetup setup        
        ) {
    }
}

Detection

Most linters warn when the arguments list is too large.

You can also detect this smell when a function signature grows over time.

Exceptions

Operations in real-world needing not cohesive collaborators.

Some low-level functions mirror external APIs or system calls.

In those cases, argument lists reflect constraints you cannot control.

Tags ️

Bloaters

Level

[X] Beginner

Why the Bijection Is Important ️

Good design keeps a clear bijection between concepts in the program and concepts in the MAPPER.

When you spread a concept across many arguments, you break that mapping.

You force callers to assemble meaning manually, and the model stops representing the domain.

AI Generation

AI generators often create this smell.

They optimize for quick success and keep adding parameters instead of creating new abstractions.

AI Detection

AI generators can fix this smell when you ask for value objects or domain concepts explicitly.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Refactor this function by grouping related parameters into meaningful domain objects and reduce the argument list to one parameter

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Relate arguments and group them.

Always favor real-world mappings. Find in real-world how to group the arguments in cohesive objects.

If a function gets too many arguments, some of them might be related to the class construction. This is a design smell too.

Relations ❤️

https://maximilianocontieri.com/code-smell-34-too-many-attributes

https://maximilianocontieri.com/code-smell-13-empty-constructors

https://maximilianocontieri.com/code-smell-87-inconsistent-parameters-sorting

Credits

Photo by Tobias Tullius on Unsplash

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Engineering DebtDrone: Building a High-Performance AST-Based Static Analyzer in Go

Fri, 19 Dec 2025 11:11:48 +0000

The Limitations of Lexical Analysis
In the world of static analysis, there is a distinct hierarchy of capability. At the bottom, you have lexical analysis—tools that treat code as a stream of strings. These are your grep-based linters. They are incredibly fast ($O(n)$ where $n$ is characters), but they are structurally blind.

To a regex linter, a function signature is just a pattern to match. It cannot reliably distinguish between a nested closure, a generic type definition, or a comment that looks like code.

When I set out to build DebtDrone, I wanted to measure Cognitive Complexity, not just cyclomatic complexity. Cyclomatic complexity counts paths through code (if/else/switch), but it fails to account for nesting. A flat switch statement with 50 cases is easy to read. A function with 3 levels of nested loops and conditionals is a maintenance nightmare.

To measure this accurately, lexical analysis is insufficient. We need Syntactic Analysis. We need a tool that understands the code structure exactly as the compiler does.

The Engine: Abstract Syntax Trees (AST)
DebtDrone leverages Tree-sitter, an incremental parsing system that builds a concrete syntax tree for a source file. Unlike abstract syntax trees (ASTs) generated by language-specific compilers (like Go's go/ast), Tree-sitter provides a unified interface for traversing trees across 11+ languages.

Parsing vs. Matching
Consider the following Go snippet:

func process(items []string) {
    if len(items) > 0 {              // +1 Nesting
        for _, item := range items { // +2 Nesting (1 + 1 penalty)
            if item == "stop" {      // +3 Nesting (2 + 1 penalty)
                return
            }
        }
    }
}

A regex tool might count the keywords if and for, giving this a score of 3. DebtDrone parses this into a tree structure. By traversing the tree, we can track nesting depth context. Every time we enter a Block node that is a child of an IfStatement or ForStatement, we increment a depth counter.

The score isn't just 1 + 1 + 1. It is weighted by depth:

Level 0: Base cost
Level 1: Base cost + 1 (Nesting penalty)
Level 2: Base cost + 2 (Nesting penalty)
This yields a "Cognitive Complexity" score that accurately reflects the mental overhead required to understand the function.

Architectural Decision: Why Go?
I chose Go for three primary architectural reasons:

Concurrency Primitives: Static analysis is an "embarrassingly parallel" problem. Each file can be parsed in isolation. Go's Goroutines and Channels allow DebtDrone to fan-out parsing tasks across all available CPU cores with minimal overhead.

Memory Safety & Speed: While Rust was a contender (and Tree-sitter has excellent Rust bindings), Go provided the fastest iteration loop for the CLI's UX and plumbing, while still offering near-C execution speed.

Single Binary Distribution: The ultimate goal was a zero-dependency binary that could drop into any CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins) without requiring a runtime like Node.js or Python.

The Engineering Challenge: CGO and Cross-Compilation
The most significant technical hurdle was the dependency on go-tree-sitter. Because Tree-sitter is implemented in C for performance, incorporating it requires CGO (CGO_ENABLED=1).

In the Go ecosystem, CGO is often considered a "dealbreaker" for easy distribution. Standard Go cross-compilation (GOOS=linux go build) is trivial because the Go compiler knows how to generate machine code for different architectures. However, once you enable CGO, you are bound by the host system's C linker.

You cannot compile a macOS binary on a Linux CI runner using the standard gcc. You need a macOS-compatible linker and system headers.

The Solution: goreleaser-cross
To solve this, I architected the release pipeline around Dockerized Cross-Compilers. Instead of relying on the bare-metal runner, the release process spins up a container (ghcr.io/goreleaser/goreleaser-cross) that contains a massive collection of cross-compilation toolchains:

o64-clang: For building macOS (Darwin) binaries on Linux.
mingw-w64: For building Windows binaries on Linux.
aarch64-linux-gnu-gcc: For ARM64 Linux builds.
This configuration is managed via .goreleaser.yaml, where we dynamically inject the correct C compiler (CC) based on the target architecture:

builds:
  - id: debtdrone-cli
    env:
      - CGO_ENABLED=1
      # Dynamic Compiler Selection
      - CC={{ if eq .Os "darwin" }}o64-clang{{ else if eq .Os "windows" }}x86_64-w64-mingw32-gcc{{ else }}gcc{{ end }}
      - CXX={{ if eq .Os "darwin" }}o64-clang++{{ else if eq .Os "windows" }}x86_64-w64-mingw32-g++{{ else }}g++{{ end }}
    goos:
      - linux
      - darwin
      - windows
    goarch:
      - amd64
      - arm64
This setup allows a standard Ubuntu GitHub Actions runner to produce native binaries for Mac (Intel/Apple Silicon), Windows, and Linux in a single pass.

Distribution Strategy: Homebrew Taps
For v1.0.0, accessibility was key. While curl | bash scripts are common, they lack version management. I implemented a custom Homebrew Tap to treat DebtDrone as a first-class citizen on macOS.

By adding a brews section to the GoReleaser config, the pipeline automatically:

Generates a Ruby formula (debtdrone.rb) with the correct SHA256 checksums.
Commits this formula to a separate homebrew-tap repository.
Allows users to install/upgrade via brew install endrilickollari/tap/debtdrone.
Beyond the Code: Impact by Role
While the engineering behind DebtDrone is fascinating, its real value lies in how it empowers different stakeholders in the software development lifecycle.

For the Developer: The "Self-Check" Before Commit
We've all been there: you're deep in the zone, solving a complex edge case. You add a flag, then a nested if, then a loop to handle a collection. It works, but you've just created a "complexity bomb."

DebtDrone acts as a mirror. By running debtdrone check . locally, you get immediate feedback:

"Warning: processTransaction has a complexity score of 25 (Threshold: 15)."

This prompts a refactor before the code even reaches a pull request. It encourages writing smaller, more composable functions, which are inherently easier to test and debug.

For the Team Lead: Objective Code Quality
Code reviews can be subjective. "This looks too complex" is an opinion; "This function has a complexity score of 42" is a fact.

DebtDrone provides an objective baseline for discussions. It helps leads identify:

Hotspots: Which files are the most dangerous to touch?
Trends: Is the codebase getting cleaner or messier over time?
Gatekeeping: Preventing technical debt from leaking into the main branch by setting hard thresholds in CI.
For DevOps: The Quality Gate
In a CI/CD pipeline, DebtDrone serves as a lightweight, fast quality gate. Because it compiles to a single binary with zero dependencies, it can be dropped into any pipeline (GitHub Actions, GitLab CI, Jenkins) without complex setup.

It supports standard exit codes (non-zero on failure) and can output results in JSON for integration with dashboarding tools. This ensures that "maintainability" is treated with the same rigor as "passing tests."

For the Business Analyst: Velocity & ROI
Why should a business care about Abstract Syntax Trees? Because complexity kills velocity.

High cognitive complexity directly correlates with:

Longer onboarding times for new developers.
Higher bug rates due to misunderstood logic.
Slower feature delivery as developers spend more time deciphering old code than writing new code.
By investing in tools like DebtDrone, organizations are investing in their long-term agility. It's not just about "clean code"—it's about sustainable development speed.

Conclusion
DebtDrone v1.0.0 represents a shift from "linting as an afterthought" to "architectural analysis as a standard." By moving from Regex to ASTs, we eliminate false positives. By solving the CGO cross-compilation puzzle, we ensure the tool is available everywhere.

The result is a CLI that runs locally, respects data privacy, and provides immediate, actionable feedback on technical debt.

GitHub Repository: endrilickollari/debtdrone-cli

Code Smell 09 - Dead Code

Tue, 16 Dec 2025 02:28:27 +0000

Code that is no longer used or needed.

TL;DR: Do not keep code "just in case I need it".

Problems

Maintainability
Extra reading
Broken intent
Wasted effort

Solutions

Remove the code
KISS
Shrink codebase
Test behavior only
Trust version control

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-021-remove-dead-code

Examples

Gold plating code or Yagni code.

Context

Dead code appears when you change requirements, and you fear deleting things.

You comment logic, keep old branches, or preserve unused methods just in case.

When you do that, you lie about what the system can actually do.

The code promises behavior that never happens.

Sample Code

Wrong

class Robot {   
  walk() {
    // ...
    }
  serialize() {
    // ..
  }
  persistOnDatabase(database) {
    // ..
  }
}

Right

class Robot {   
  walk() {
    // ...
    }  
}

Detection

Coverage tools can find dead code (uncovered) if you have a great suite of tests.

Exceptions

Avoid metaprogramming. When used, it is very difficult to find references to the code.

https://maximilianocontieri.com/laziness-i-meta-programming

Tags ️

YAGNI

Level

[x] Beginner

Why the Bijection Is Important ️

Your program must mirror the MAPPER with a clear bijection

Dead code breaks that mapping. The domain has no such behavior, yet the code claims it exists.

When you do that, you destroy trust.

Readers cannot know what matters and what does not.

AI Generation

AI generators often create dead code.

They add defensive branches, legacy helpers, and unused abstractions to look complete.

When you do not review the result, the smell stays.

AI Detection

AI tools can remove this smell with simple instructions.

You can ask them to delete unreachable code and align logic with tests.

They work well when you already have coverage.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: correct=remove dead code

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Remove dead code for simplicity.

If you are uncertain of your code, you can temporarily disable it using Feature Toggle.

Removing code is always more rewarding than adding.

Relations ❤️

https://maximilianocontieri.com/code-smell-54-anchor-boats

More Information

https://maximilianocontieri.com/laziness-i-meta-programming

Credits

Photo by Ray Shrewsberry on Pixabay

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 316 - Nitpicking

Sun, 14 Dec 2025 02:42:18 +0000

When syntax noise hides real design problems

TL;DR: When you focus code reviews on syntax, you miss architecture, security, design and intent.

Problems

Syntax fixation
Design blindness
Missed risks
Bad feedback
Useless discussions
Reviewer fatigue
False quality
Shallow feedback
Syntax Police
Low team morale

Solutions

Leave the boring work to the IA
Automate style checks
Review architecture first
Discuss intent early with technical analysis and control points
Enforce review roles
Raise abstraction level

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-032-apply-consistent-style-rules

https://maximilianocontieri.com/refactoring-016-build-with-the-essence

Context

When you review code, you choose where to spend your valuable human attention.

When you spend that attention on commas, naming trivia, or formatting, you ignore the parts that matter.

This smell appears when teams confuse cleanliness with correctness. Syntax looks clean. Architecture rots.

Sample Code

Wrong ❌

<?php

class UserRepository {
    public function find($id){
        $conn = mysqli_connect(
             "localhost", // Pull Request comment - Bad indentation
            "root",
            "password123",
            "app"
        );

        $query = "Select * FROM users WHERE id = $id";
        // Pull Request comment - SELECT should be uppercase
        return mysqli_query($conn, $query);
    }
}

Right

<?php

final class UserRepository {
    private Database $database;

    public function __construct(Database $database) {
        $this->database = $database;
    }

    public function find(UserId $id): User {
        return $this->database->fetchUser($id);
    }
}

// You removed credentials, SQL, and infrastructure noise.
// Now reviewers can discuss design and behavior.

Detection

[X] Manual

You can detect this smell by examining pull request comments.

When you see multiple comments about formatting, indentation, trailing commas, or variable naming conventions, you lack proper automation.

Check your continuos integration pipeline configuration. If you don't enforce linting and formatting before human review, you force reviewers to catch these issues manually.

Review your code review metrics. If you spend more time discussing style than architecture, you have this smell.

Automated tools like SonarQube, ESLint, and Prettier can identify when you don't enforce rules automatically.

Tags ️

Standards

Level

[x] Intermediate

Why the Bijection Is Important ️

Code review represents the quality assurance process in the MAPPER.

When you break the bijection by having humans perform mechanical checks instead of judgment-based evaluation, you mismodel the review process.

You no longer validate whether the concepts, rules, and constraints match the domain.

You only validate formatting.

That gap creates systems that look clean and behave wrong.

The broken bijection manifests as reviewer fatigue and missed bugs. You restore proper mapping by separating mechanical verification (automated) from architectural review (human).

AI Generation

AI generators often create this smell.

They produce syntactically correct code with weak boundaries and unclear intent.

AI Detection

AI can reduce this smell when you instruct it to focus on architecture, invariants, and risks instead of formatting.

Give them clear prompts and describe the role and skills of the reviewer.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Find real problems in the code beyond nitpicking, review this code focusing on architecture, responsibilities, security risks, and domain alignment. Ignore formatting and style.

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Code reviews should improve systems, not satisfy linters.

When you automate syntax, you free humans to think.

That shift turns reviews into real design conversations.

Relations ❤️

https://coderlegion.com/8216/code-smell-06-too-clever-programmer

https://maximilianocontieri.com/code-smell-48-code-without-standards

https://coderlegion.com/8106/code-smell-05-comment-abusers

https://maximilianocontieri.com/code-smell-173-broken-windows

https://maximilianocontieri.com/code-smell-236-unwrapped-lines

Disclaimer

Code Smells are my opinion.

Credits

Photo by Portuguese Gravity on Unsplash

Design is about intent, not syntax.

Grady Booch

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 06 - Too Clever Programmer

Sat, 06 Dec 2025 00:33:31 +0000

Code is hard to read when you use tricky names with no semantics or rely on accidental language complexity.

TL;DR: Don't try to look too smart. Clean code emphasizes readability and simplicity.

Problems

Readability
Maintainability
Code Quality
Premature Optimization

Solutions

Refactor the code
Use good names
Refactor tricky code
Prefer clarity first
Avoid hidden tricks
Optimize only later with strong real evidence

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-005-replace-comment-with-function-name

Examples

Optimized loops

Context

You might feel the urge to show off your skills with complex tricks or cryptic names.

This makes your code harder to read, debug, and extend.

You must remember that you write code for humans, not machines.

Sample Code

Wrong

function primeFactors(n) {
  var f = [],  i = 0, d = 2;  
  
  for (i = 0; n >= 2; ) {
     if(n % d == 0) {
       f[i++]=(d); 
       n /= d;
    }
    else {
      d++;
    }     
  }
  return f;
}

Right

function primeFactors(numberToFactor) {
  var factors = [], 
      divisor = 2,
      remainder = numberToFactor;
  
  while(remainder>=2) {
    if(remainder % divisor === 0) {
       factors.push(divisor); 
       remainder = remainder / divisor;
    }
    else {
      divisor++;
    }     
  }
  return factors;
}

Detection

[X] Semi-Automatic

Automatic detection is possible in some languages.

Look for warnings about complexity, bad names, post-increment variables, and similar patterns.

Exceptions

Optimized code for low-level operations.

Tags ️

Complexity

Level

[X] Intermediate

Why the Bijection Is Important ️

When you keep a clear bijection between your program and the MAPPER.

Other developers and your future self can understand it quickly.

Clever tricks break this mapping and force future readers to guess instead of reading.

AI Generation

AI models sometimes generate clever one-liners or compressed solutions.

They might look smart but lack readability and semantics.

AI Detection

AI assistants can rewrite clever code into readable code if you instruct them to prefer clarity to optimization.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: correct=Remove cleverness from code

Conclusion

Clever developers write cryptic code to brag.

Smart developers write clean code.

Clear beats clever.

Relations ❤️

https://coderlegion.com/7475/code-smell-02-constants-and-magic-numbers

https://maximilianocontieri.com/code-smell-20-premature-optimization

https://maximilianocontieri.com/code-smell-44-magic-corrections

https://maximilianocontieri.com/code-smell-41-regular-expression-abusers

https://maximilianocontieri.com/code-smell-78-callback-hell

https://maximilianocontieri.com/code-smell-51-double-negatives

https://maximilianocontieri.com/code-smell-33-abbreviations

https://maximilianocontieri.com/code-smell-48-code-without-standards

https://maximilianocontieri.com/code-smell-196-javascript-array-constructors

https://maximilianocontieri.com/code-smell-25-pattern-abusers

https://maximilianocontieri.com/code-smell-93-send-me-anything

https://maximilianocontieri.com/code-smell-145-short-circuit-hack

https://maximilianocontieri.com/code-smell-212-elvis-operator

https://maximilianocontieri.com/code-smell-180-bitwise-optimizations

https://maximilianocontieri.com/code-smell-129-structural-optimizations

https://maximilianocontieri.com/code-smell-32-singletons

https://maximilianocontieri.com/code-smell-21-anonymous-functions-abusers

https://maximilianocontieri.com/code-smell-24-boolean-coercions

https://maximilianocontieri.com/code-smell-69-big-bang-javascript-ridiculous-castings

More Information

https://ardalis.com/are-boolean-flags-on-methods-a-code-smell/

Also Known as

Obfuscator

Credits

Photo by NeONBRAND on Unsplash

Programming can be fun, so can cryptography; however they should not be combined.

Kreitzberg & Shneiderman

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 05 - Comment Abusers

Wed, 03 Dec 2025 00:17:10 +0000

The code has lots of comments. Comments are coupled to implementation and hardly maintained.

TL;DR: Leave comments just for important design decisions. Don't explain the obvious.

Problems

Maintainability
Obsolete Documentation
Readability
Duplication between code and comments

Solutions

1) Refactor methods.

2) Rename methods with more declarative names.

3) Break down large methods.

4) If a comment describes what a method does, name the method with this description.

5) Just comment on important design decisions.

https://maximilianocontieri.com/what-exactly-is-a-name-part-i-the-quest

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-005-replace-comment-with-function-name

https://maximilianocontieri.com/refactoring-011-replace-comments-with-tests

https://maximilianocontieri.com/refactoring-002-extract-method

Examples

Libraries
Class Comments
Method Comments

Context

You write comments when you feel your code does not speak by itself.

Most of the time, you add noise instead of clarity.

Later, those comments lie when you change the code but forget to update the explanation.

Instead of helping, they hurt.

Sample Code

Wrong

<?

final class ChatBotConnectionHelper {
    // ChatBotConnectionHelper is used
    // to create connection strings to Bot Platform
    // Use this class with getString() function
    // to get connection string to platform

    function getString() {
        // Get Connection String from Chatbot
    }
}

Right

<?

final class ChatBotConnectionSequenceGenerator {

    function connectionSequence() {
    }
}

Detection

[X] Semi-Automatic

Linters can detect comments and check the ratio of comments to lines of code against a predefined threshold.

Tags ️

Comments

Level

[X] Beginner

Why the Bijection Is Important ️

Your software should reflect the domain with no translators in between.

When you use comments as crutches, you break the one-to-one mapping between the real-world concept and its code representation.

This mismatch creates confusion and bugs.

AI Generation

AI tools often generate comments to explain code in natural language.

This can pollute your source when the code already speaks for itself.

AI Detection

AI tools can easily remove redundant comments and suggest clearer names.

You only need to instruct them to "remove obvious comments and refactor for clarity."

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: correct=Remove all Comments

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Leave comments just for important design decisions. Don't comment on a method with a bad name, rename it.

Relations ❤️

https://maximilianocontieri.com/code-smell-75-comments-inside-a-method

https://maximilianocontieri.com/code-smell-57-versioned-functions

https://maximilianocontieri.com/code-smell-168-undocumented-decisions

https://maximilianocontieri.com/code-smell-151-commented-code

https://maximilianocontieri.com/code-smell-183-obsolete-comments

https://maximilianocontieri.com/code-smell-146-getter-comments

More Information

https://refactoring.guru/es/smells/comments

https://maximilianocontieri.com/what-exactly-is-a-name-part-i-the-quest

https://dev.to/alexbunardzic/code-comments-are-a-sign-that-something-s-off-19e1

https://arter.dev/how-to-comment-your-code-like-a-boss

Credits

Photo by Volodymyr Hryshchenko on Unsplash

If you have to spend effort looking at a fragment of code and figuring out what it’s doing, then you should extract it into a function and name the function after the what.

Martin Fowler

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 315 - Cloudflare Feature Explosion

Sat, 29 Nov 2025 22:18:03 +0000

When bad configuration kills all internet proxies

TL;DR: Overly large auto-generated config can crash your system.

Problems

Config overload
Hardcoded limit
Lack of validations
Crash on overflow
Fragile coupling
Cascading Failures
Hidden Assumptions
Silent duplication
Unexpected crashes
Thread panics in critical paths
Treating internal data as trusted input
Poor observability
Single point of failure in internet infrastructure

Solutions

Validate inputs early
Enforce soft limits
Fail-fast on parse
Monitor config diffs
Version config safely
Use backpressure mechanisms
Degrade functionality gracefully
Log and continue
Improve degradation metrics
Implement proper Result/Option handling with fallbacks
Treat all configuration as untrusted input

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-004-remove-unhandled-exceptions

https://maximilianocontieri.com/refactoring-024-replace-global-variables-with-dependency-injection

https://maximilianocontieri.com/refactoring-035-separate-exception-types

Context

In the early hours of November 18, 2025, Cloudflare’s global network began failing to deliver core HTTP traffic, generating a flood of 5xx errors to end users.

This was not caused by an external attack or security problem.

The outage stemmed from an internal "latent defect" triggered by a routine configuration change

The failure fluctuated over time, until a fix was fully deployed.

The root cause lay in a software bug in Cloudflare’s Bot Management module and its downstream proxy logic.

The Technical Chain of Events

Database Change (11:05 UTC): A ClickHouse permissions update made previously implicit table access explicit, allowing users to see metadata from both the default and r0 databases.
SQL Query Assumption: A Bot Management query lacked a database name filter:
```
SELECT name, type FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;
```
This query began returning duplicate rows—once for default database, once for r0 database.
Feature File Explosion: The machine learning feature file doubled from ~60 features to over 200 features with duplicate entries.
Hard Limit Exceeded: The Bot Management module had a hard-coded limit of 200 features (for memory pre-allocation), which was now exceeded.
The Fatal .unwrap(): The Rust code called .unwrap() on a Result that was now returning an error, causing the thread to panic with "called Result::unwrap() on an Err value". see code below
Global Cascade: This panic propagated across all 330+ data centers globally, bringing down core CDN services, Workers KV, Cloudflare Access, Turnstile, and the dashboard.

The estimated financial impact across affected businesses ranges from $180-360 million.

Sample Code

Wrong ❌

let features: Vec<Feature> = load_features_from_db();
let max = 200;
assert!(features.len() <= max);
# This magic number assumption 
# is actually wrong                              
                              
for f in features {
    proxy.add_bot_feature(f.unwrap());
    # You also call unwrap() on every feature. 
    # If the database returns an invalid entry 
    # or a parsing error,
    # you trigger another panic. 
    # You give your runtime no chance to recover. 
    # You force a crash on a single bad element.
}
                              
# A quiet config expansion turns into
# a full service outage 
# because you trust input that you should validate 
# and you use failure primitives (assert!, unwrap()) 
# that kills your program 
# instead of guiding it to safety

Right

fn load_and_validate(max: usize) -> Result<Vec<Feature>, String> {
    let raw: Vec<Result<Feature, Error>> = load_features_from_db();
    
    if raw.len() > max {
        return Err(format!(
            "too many features: {} > {}", 
            raw.len(), max
        ));
    }
    
    Ok(raw.into_iter()
        .filter_map(|r| r.ok())
        .collect())
}

Detection

You can detect this code smell by searching your codebase for specific keywords:

.unwrap() - Any direct call to this method
.expect() - Similarly dangerous
panic!() - Explicit panics in non-test code
thread::panic_any() - Panic without context

When you find these patterns, ask yourself: "What happens to my system when this Result contains an Err?" If your honest answer is "the thread crashes and the request fails," then you've found the smell.

You can also use automated linters. Most Rust style guides recommend tools like clippy, which flags unwrap() usage in production code paths.

When you configure clippy with the #![deny(unwrap_in_result)] attribute, you prevent new unwrap() calls from entering your codebase.

Tags ️

Fail-Fast

Level

[x] Advanced

Why the Bijection Is Important ️

Your internal config generator must map exactly what your code expects.

A mismatched config (e.g., duplicated metadata) breaks the bijection between what your config represents and what your proxy code handles.

When you assume "this file will always have ≤200 entries", you break that mapping.

Reality sends 400 entries → your model explodes → the real world wins, your service loses.

That mismatch causes subtle failures that cascade, especially when you ignore validation or size constraints.

Ensuring a clean mapping between the config source and code input helps prevent crashes and unpredictable behavior.

AI Generation

AI generators often prioritize correct logic over resilient logic.

If you ask an AI to "ensure the list is never larger than 200 items," it might generate an assertion or a panic because that is the most direct way to satisfy the requirement, introducing this smell.

The irony: Memory-safe languages like Rust prevent undefined behavior and memory corruption, but they can't prevent logic errors, poor error handling, or architectural assumptions.

Memory safety ≠ System safety.

AI Detection

AI can easily detect this if you instruct it to look for availability risks.

You can use linters combined with AI to flag panic calls in production code.

Human review on critical functions is more important than ever.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: remove all .unwrap() and .expect() calls. Return Result instead and validate the vector bounds explicitly

Conclusion

Auto-generated config can hide duplication or grow unexpectedly.

If your code assumes size limits or blindly trusts its input, you risk a catastrophic crash.

Validating inputs is good; crashing because an input is slightly off is a disproportionate response that turns a minor defect into a global outage.

Validate config, enforce limits, handle failures, and avoid assumptions.

That’s how you keep your system stable and fault-tolerant.

Relations ❤️

https://maximilianocontieri.com/code-smell-122-primitive-obsession

https://coderlegion.com/7475/code-smell-02-constants-and-magic-numbers

https://maximilianocontieri.com/code-smell-198-hidden-assumptions

More Information

https://techcrunch.com/2025/11/18/cloudflare-blames-massive-internet-outage-on-latent-bug/

https://www.cloudflarestatus.com/incidents/8gmgl950y3h

https://techcrunch.com/2025/11/18/cloudflare-blames-massive-internet-outage-on-latent-bug/

https://mgx.dev/blog/cloudflare1119

https://hackaday.com/2025/11/20/how-one-uncaught-rust-exception-took-out-cloudflare/

https://www.cnbc.com/2025/11/18/cloudflare-outage-briefly-takes-chatgpt-claude-services-offline.html

Disclaimer

Code Smells are my opinion.

A good programmer is someone who always looks both ways before crossing a one-way street

Douglas Crockford

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 04 - String Abusers

Fri, 28 Nov 2025 23:13:52 +0000

Too much parsing, exploding, regex, strcmp, strpos and string manipulation functions.

TL;DR: Use real abstractions and real objects instead of accidental string manipulation.

Problems

Complexity
Readability
Maintainability
Lack of abstractions
Fragile logic
Hidden intent
Hard debugging
Poor modeling
Regex mess

Solutions

1) Work with objects instead.

2) Replace strings with data structures dealing with object relations.

3) Go back to Perl :)

4) identify bijection problems between real objects and the strings.

Examples

Serializers
Parsers

Context

When you abuse strings, you try to represent structured concepts with plain text.

You parse, explode, and regex your way around instead of modeling the domain.

This creates fragile code that breaks with small input changes.

Sample Code

Wrong

<?php

$schoolDescription = 'College of Springfield';

preg_match('/[^ ]*$/', $schoolDescription, $results);
$location = $results[0]; // $location = 'Springfield'.

$school = preg_split('/[\s,]+/', $schoolDescription, 3)[0]; 
//'College'

Right

<?

class School {
    private $name;
    private $location;

    function description() {
        return $this->name . ' of ' . $this->location->name;
    }
}

Detection

[X] Semi-Automatic

Automated detection is not easy.

If your code uses too many string functions, linters can trigger a warning.

Tags ️

Primitive Obsession

Level

[X] Beginner

Why the Bijection Is Important ️

You must mirror the real-world domain in your code.

When you flatten roles, addresses, or money into raw strings, you lose control.

This mismatch leads to errors, duplication, and weak models.

One-to-one mapping between domain and code gives you clarity and robustness.

AI Generation

AI generators often produce string-abusing code because it looks shorter and easier.

The generated solution can be correct for toy cases but fragile in real systems.

AI Detection

You can instruct AI tools to replace string checks with domain objects.

With clear prompts, AI can spot and fix string abuse effectively.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Reify Strings to objects

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Don't abuse strings.

Favor real objects.

Add missing protocol to distinguish them from raw strings.

Relations ❤️

https://maximilianocontieri.com/code-smell-122-primitive-obsession

https://maximilianocontieri.com/code-smell-121-string-validations

https://maximilianocontieri.com/code-smell-295-string-concatenation

More Information

Credits

Photo by Nathaniel Shuman on Unsplash

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 03 - Functions Are Too Long

Sat, 22 Nov 2025 14:35:23 +0000

Humans get bored after line five.

TL;DR: Refactor and extract functions longer than five lines.

Problems

Low cohesion
High coupling
Hard to read
Low reusability

Solutions

1) Refactor

2) Create small objects to handle specific tasks. Unit-test them.

3) Compose methods

4) Divide and conquer

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-010-extract-method-object

https://maximilianocontieri.com/refactoring-025-decompose-regular-expressions

https://maximilianocontieri.com/refactoring-002-extract-method

Examples

Libraries

Context

When you write a long function, you hide too many details in one place.

You force the reader to hold multiple concepts in mind.

You mix unrelated responsibilities and make the code hard to test.

You create a rigid block that breaks easily when you change it.

Short, focused functions let you read, test, and modify code faster.

Sample Code

Wrong

[Gist Url]: # (https://gist.github.com/mcsee/1f12fb2d0cb9f8eea202526597cf4b83)

<?

function setUpChessBoard() {
    $this->placeOnBoard($this->whiteTower);
    $this->placeOnBoard($this->whiteKnight);
    // A lot more lines
    
    // Empty space to pause definition
    $this->placeOnBoard($this->blackTower);
    $this->placeOnBoard($this->blackKnight);
    // A lot more lines
}

Right

[Gist Url]: # (https://gist.github.com/mcsee/0f66ce8c2bba8990e44a36495fa4c3e1)

<?

function setUpChessBoard() {
    $this->placeWhitePieces();
    $this->placeBlackPieces();
}

Detection

[X] Automatic

All linters can measure and warn when methods exceed a predefined threshold.

Tags ️

Bloaters

Level

[X] Beginner

Why the Bijection Is Important ️

A real-world action should map to a clear, concise function.

When you pack many actions into one function, you lose that mapping.

Developers must mentally reconstruct the steps, which slows comprehension and increases errors.

AI Generation

AI generators often create long functions if you give them vague prompts.

They tend to cram all logic into one place unless you explicitly request modular code.

AI Detection

AI tools can fix this smell with the right instructions to split code into small, focused functions.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Break long functions using extract method refactoring

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

Extract long methods into smaller pieces.

Break complex algorithms into parts.

You can also unit test these parts.

Relations ❤️

https://maximilianocontieri.com/code-smell-75-comments-inside-a-method

https://maximilianocontieri.com/code-smell-102-arrow-code

https://maximilianocontieri.com/code-smell-206-long-ternaries

https://maximilianocontieri.com/code-smell-107-variables-reuse

https://maximilianocontieri.com/code-smell-74-empty-lines

https://maximilianocontieri.com/code-smell-154-too-many-variables

https://maximilianocontieri.com/code-smell-83-variables-reassignment

More Information

https://refactoring.guru/es/smells/long-method

Also Known as

Long Method

Credits

Photo by Hari Panicker on Unsplash

Programs are meant to be read by humans and only incidentally for computers to execute.

Donald Knuth

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 02 - Constants and Magic Numbers

Tue, 18 Nov 2025 14:43:55 +0000

A method makes calculations with lots of numbers without describing their semantics

TL;DR: Avoid Magic numbers without explanation. You don't know their source and are very afraid of changing them.

Problems

Coupling
Low testability
Low readability

Solutions

1) Rename the constant to a meaningful, intention-revealing name.

2) Replace constants with parameters, so you can mock them from the outside.

3) The constant definition is often a different object than the constant (ab)user.

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-003-extract-constant

https://maximilianocontieri.com/refactoring-025-decompose-regular-expressions

Examples

Algorithms Hyper Parameters

Context

Magic numbers are literal values embedded directly into your code without explanation.

They often appear in algorithms, configuration rules, or business logic as unexplained numeric values.

At first, they might feel faster to write, but over time they turn into hidden assumptions that no one remembers.

Future maintainers must guess their meaning, increasing the risk of errors when the values need to change.

Constants help, but naming them meaningfully and placing them in the right context is what turns a magic number into a reliable, self-explanatory part of your code.

Sample Code

Wrong

<?

function energy($mass) {
    return $mass * (299792 ** 2)
}

Right

# Storing magnitudes without units is another smell
class PhysicsConstants
   LIGHT_SPEED = 299792458.freeze
end

def energy(mass)
    mass * PhysicsConstants::LIGHT_SPEED ** 2
end

Detection

[X] Semi-Automatic

Many linters can detect number literals in attributes and methods.

Tags ️

Declarative Code

Level

[X] Beginner

Why the Bijection Is Important ️

When you replace a magic number with a named constant, you create a bijection between the value and its meaning.

This one-to-one relationship ensures every numeric value has a clear, unambiguous purpose in your system.

Without it, the same number could be reused for different reasons, leading to confusion and accidental coupling.

A bijection between meaning and value makes the code easier to navigate, test, and evolve without fear of breaking unrelated parts.

AI Generation

Large Language Models can introduce magic numbers when generating code, especially in examples or algorithm implementations.

Treat AI-generated values with the same suspicion you would any human-written literal.

Always check if the number is a placeholder, a real-world constant, or an algorithmic parameter, and replace it with a meaningful name before merging it into production code.

AI Detection

Code reviewers should stay alert to magic numbers introduced by AI tools, which often lack context or semantic naming.

Automated linters can flag number literals, but human insight is critical to understand if a value requires refactoring into a named constant.

Keep your eyes open for AI-generated black box numbers that might slip past initial checks but can cause maintenance headaches later.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Replace Magic numbers with constants

Without Proper Instructions	With Specific Instructions
ChatGPT	ChatGPT
Claude	Claude
Perplexity	Perplexity
Copilot	Copilot
You	You
Gemini	Gemini
DeepSeek	DeepSeek
Meta AI	Meta AI
Grok	Grok
Qwen	Qwen

Conclusion

You should address and remove your magic numbers to safeguard your code's readability, maintainability, and testability.

Clear, semantic naming and decoupling constants from their consumers are essential steps toward crafting cleaner, more resilient software.

Every magic number you replace with intention-revealing logic is a step away from brittle code and closer to robust, professional craftsmanship.

Don't let numbers dictate your code; define their purpose and context instead.

Relations ❤️

https://maximilianocontieri.com/code-smell-158-variables-not-variable

https://maximilianocontieri.com/code-smell-127-mutable-constants

https://maximilianocontieri.com/code-smell-06-too-clever-programmer

https://maximilianocontieri.com/code-smell-162-too-many-parentheses

https://maximilianocontieri.com/code-smell-198-hidden-assumptions

https://maximilianocontieri.com/code-smell-202-god-constant-class

More Information

https://refactoring.guru/es/replace-magic-number-with-symbolic-constant

https://maximilianocontieri.com/how-to-decouple-a-legacy-system

Credits

Photo by Kristopher Roller on Unsplash

In a purely functional program, the value of a [constant] never changes, and yet, it changes all the time! A paradox!

Joel Spolsky

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code

Code Smell 01 - Anemic Models

Wed, 12 Nov 2025 12:41:16 +0000

Your objects have no behavior.

TL;DR: Don't use objects as data structures

Problems

Lack of encapsulation
No mapping to real-world entities
Duplicated Code
Coupling
Writer / Reader mismatch
Missing behavior

Solutions

1) Find Responsibilities.

2) Protect your attributes.

3) Hide implementations.

4) Follow Tell-Don't-Ask principle

Refactorings ⚙️

https://maximilianocontieri.com/refactoring-016-build-with-the-essence

https://maximilianocontieri.com/refactoring-009-protect-public-attributes

https://maximilianocontieri.com/refactoring-001-remove-setters

Examples

DTOs

Context

If you let your objects become data buckets, you kill the connection between your logic and your language.

Anemic models are classes that contain only data (properties) with little or no behavior.

They're essentially glorified data structures with getters and setters.

When you create anemic models, you end up putting all the logic that should live in these objects into service classes instead duplicated the logic across multiple services.

This approach breaks object-oriented principles by separating data from the behavior that manipulates it.

You'll find yourself writing procedural code that pulls data out of objects, performs operations on it, and then pushes the results back in.

This creates tight coupling between your services and objects, making your codebase harder to maintain and evolve.

When you identify an anemic model in your code, it's a sign that you're missing opportunities for better encapsulation and more intuitive object design.

Rich domain models lead to code that's more maintainable, testable, and closer to how you think about the problem domain.

Sample Code

Wrong ❌

[Gist Url]: # (https://gist.github.com/mcsee/73f84d80f7c3e89a216dd9e40ab71bcc)

public class Song {
   String name;
   String authorName;
   String albumName;
}

Right

[Gist Url]: # (https://gist.github.com/mcsee/78f2dd78120db843c960ed41839f29cb)

public class Song {
   private String name;
   private Artist author; // Will reference rich objects
   private Album album; // instead of primitive data types

   public String albumName() {
     return album.name() ;
}

Detection

[X] Semi-Automatic

Sophisticated linters can automate detection.

They should ignore setters and getters and count real behavior methods.

Tags ️

Anemic Models

Level

[X] Beginner

Why the Bijection Is Important ️

If we ask a domain expert to describe an entity he/she would hardly tell it is 'a bunch of attributes'.

The power of object-oriented programming comes from modeling real-world concepts directly in code.

When you create anemic models, you break the bijection between the domain and your code.

AI Generation

AI code generators often produce anemic models because they follow common but flawed patterns found in many codebases.

When you ask an AI to generate a basic model class, it will typically create a class with properties and getters/setters but no behavior.

This perpetuates the anemic model anti-pattern.

You need to specifically instruct AI tools to generate rich domain models with behavior, not just data holders.

Be explicit in your prompts about including relevant methods that encapsulate business logic within the model.

AI Detection

AI tools can help identify anemic models with simple instructions like "find classes with many getters/setters but few business methods" or "identify service classes that should be refactored into domain models."

Determining which behavior truly belongs in a model requires domain knowledge and design judgment that current AI tools lack.

AI can flag potential issues, but you still need to make the final decision about where behavior belongs.

Try Them!

Remember: AI Assistants make lots of mistakes

Suggested Prompt: Convert the anemic object into a rich one focusing on behavior instead of structure

Conclusion

Anemic models might seem convenient at first, but they lead to scattered logic, poor encapsulation, and maintenance headaches.

Senior developers create rich domain models focusing on their behavior.

By moving logic from services into models, you create code that's more intuitive, maintainable, and aligned with object-oriented principles.

Your objects should do things, not just store data.

Avoid anemic models. Focus always on protocol instead of data.

behavior is essential, data is accidental.

Relations ❤️

https://maximilianocontieri.com/code-smell-28-setters

https://maximilianocontieri.com/code-smell-15-missed-preconditions-1

https://maximilianocontieri.com/code-smell-210-dynamic-properties

More Information

https://en.wikipedia.org/wiki/Anemic_domain_model

https://refactoring.guru/es/smells/data-class

https://maximilianocontieri.com/nude-models-part-i-setters

https://maximilianocontieri.com/nude-models-part-ii-getters

https://maximilianocontieri.com/how-to-decouple-a-legacy-system

Also Known as

Data Class

Disclaimer

Code Smells are my opinion.

Credits

Photo by Stacey Vandergriff on Unsplash

Object-oriented programming increases the value of these metrics by managing this complexity. The most effective tool available for dealing with complexity is abstraction. Many types of abstraction can be used, but encapsulation is the main form of abstraction by which complexity is managed in object-oriented programming.

Rebecca Wirfs-Brock

https://maximilianocontieri.com/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://maximilianocontieri.com/how-to-find-the-stinky-parts-of-your-code